
Just Build the Product - davnicwil
https://davnicwil.com/just-build-the-product/
======
tombert
You know, one of these posts pops up on HN every few months, and every time it
kind of annoys me.

If I'm building a project for fun at home, then it's typically _specifically_
to learn about a new thing (which I kind of assumed was the case for most
people); either a new programming language, or a new editor, or a new library
or two. If I short-circuit and "just build the product", then that is sort of
negating the purpose of the project.

If I wanted to "just get something done", I probably wouldn't have done any
projects in Haskell (back when it _really_ sucked for tooling), I wouldn't
have learned category theory, and I wouldn't have gotten any work in research.

~~~
mathgladiator
It annoys me as well, and I think the intent is that "just build the product"
is about avoiding shaving the yak.

Some of us poor bastards have to invent the stupid things that let people get
things done, and it isn't exactly clear that the stupid thing is even good in
the first place.

For instance, right now, I am in the process of inventing my own programming
language. I've done this in the past with varying degrees of technical
success, but it tends to get deep into the weeds of shaving the yak and
polishing it up.

I'm have a hell of time to pull myself from the technically interesting
problems to focus on the product that this language enables, and I find myself
having to balance between fixing the language idioms and building the product.

Balance will be a key thing to focus on if I make this product a real thing
for real customers... very challenging future ahead of myself.

~~~
capableweb
> It annoys me as well, and I think the intent is that "just build the
> product" is about avoiding shaving the yak.

I think discussions in general on Hacker News, blogposts and Twitter is
missing context. Everyone assumes that others context is the same that you
yourself has. So posts like this make sense, if you're in "startup - lets find
market fit - need growth - just build the damn thing" mode, which is probably
the mode the author is, or the context would have been set in the blogpost.

In the comment you're replying to, the context is a "explore an idea and learn
something new" with no intention on turning that very thing into a product
that sells to people. Maybe that will happen, but it's not the intention.

In the end, two very different contexts, both valid, but they are both talking
past each other. All the people using different social networks (HN included),
usually miss the vital piece of context and just proclaim "You should do X,
because of Y". Then people defend their context, because life is never "Always
do X" and will never be.

~~~
0xFACEFEED
Good point. But isn't it the author's job to establish context? Otherwise what
they're saying is typical "thought leader" platitude nonsense.

Here's another way of looking it. Shipping a product involves thousands of
decisions and course corrections. Sometimes technical decisions like deciding
on a build system or programming language. Other times product decisions like
deciding to ship without user login and use an email "magic link" instead. And
other times it involves building no product at all and just gathering some
user feedback on the idea.

So if you look at it that way, "just build the product" is total nonsense no
matter what context you're in. It's the ability to make good decisions that
matters. What's a good decision? One that produces the results you're happy
with (expected or not).

How do you make good decisions? Well, that's the hard part. The OP doesn't
help at all. It's just fluff.

Example: You're working on a product idea. One of the core features is a
DSL/language that the user types in a GUI to make some magical thing happen.
Immediately you're faced with choices about your DSL/language. Should it be a
subset/superset of another language? Should it be totally custom? Should you
write your own parser? Should you use a parser generator? If you use a parser
generator, how will you handle lax/incremental parsing?

If it were me I'd spend a couple weeks researching PL theory. In the process I
might learn about the tradeoffs of choosing LL/LR/LALR grammars. Maybe I'll
learn about state of the art grammar generators that'll save me weeks of
coding and months (cumulatively) of debugging. Did I waste my time or did I
just greatly improve my _core_ product?

Another week later you're faced with decision of choosing a build system.
Since your product will only ever run on AWS somewhere you write a simple
Makefile and move forward. No point in diving deep into the likes of
CMake/build2/etc if you don't have to. Could it bite you later? Maybe. If it
does you'll deal with it.

Where does "just build the product" help here? Building the product _is_
making these decisions thousands of times.

Oh boy, I'm ranting. I'll just press Reply now :P

~~~
Falkon1313
>How do you make good decisions?

Good decisions come from wisdom. Wisdom comes from making bad decisions. Just
make the decisions and learn from that. That's my interpretation of the post.

I sometimes do projects to learn new tools, and sometimes just to try to make
something I want to play with. Sometimes it's good, sometimes it's not. But a
couple of years later I might come back and revisit it with new knowledge and
perspectives.

It's easy to get lost in the labyrinth of second-system syndrome and analysis
paralysis and not really do the thing at all. Maybe better to do it with tech
debt and sort it out later if it's worth it, and if not then learn from that.
But still with a focus on the goals, not the means to get there.

------
tristanstcyr
Rather facile advice.

As a software engineer, it's your responsibility to build the product
according to the requirements. Sometimes that means it needs to be built it
quick because it's likely to have a short life, or it needs to land quickly to
market. Sometimes, you need to get things right, otherwise you end with an
insurmountable amount of technical debt and a business that grinds to a halt.

Given this, you should make the analysis to understand the tools that you
need. If that means learning, then so be it. Maybe you can keep going with
superficial knowledge. Or, perhaps you need to find an expert, that's fine
too.

As for growing in your technical knowledge, that should be agreed upon with
your employer or whoever is paying for the work. If you find that you work
somewhere that doesn't allow you to learn then perhaps it's not the right
place to be.

Think like a professional.

~~~
gfodor
The problem is it’s extremely hard or often impossible to know what are good
choices before you’ve started building the product. This, combined with the
fact that software is highly malleable, should lead one to highly prefer a
bias towards action vs analysis. It’s not a hard rule, but it’s much more
common for people to fail due to analysis paralysis than due to poor
technology choices. If you are able to get any form of traction, opportunities
open up to expand resources and time that will be needed to adjust
technologies. It won’t necessarily be fun, but when going through such an
experience I believe more often than not engineers have hindsight bias, not a
true recognition that early choices were made objectively incorrect given the
knowledge at the time.

~~~
hinkley
I’ve seen plenty of project grind to a halt from bad decisions and high pain
thresholds. I think you’ll find and even mix in the overanalysis crowd of
white tower thinkers and people exhibiting allergic reactions. If you are
seeing more of the latter I have two theories. One, those people gatekeepe
projects, so once bitten twice shy (ie they accumulate and add friction) or
two, you are looking at more early phase startups than me. A seed phase
startup locked in analysis never sees my resume, so I don’t see how often that
happens.

But the trick is to start with the new Reversible decisions.

We don’t always know which are the reversible decisions, but many of the
irreversible ones are obvious. For some reason developers always focus on the
irreversible one. We reason that we have to get this right, because it’s very
important. And if it’s important, we should do it first.

No. No. No.

If instead you start tackling all the reversible decisions first, you can make
those choices quickly (because changing them is cheap, spending a lot of
energy on making them is a waste of time and capital). Start building
something. Get momentum. Get the team and ideas to gel.

When you start to know what you’re doing, then tackle the irreversible
decisions one at a time.

But typically, everyone wants to Decide. And they want _you_ to decide on
short notice, right now, like some sort of used car salesman. If we don’t
tolerate this from others, why do we tolerate it from our teammates?

Deciding for the sake of deciding is not productivity. It’s painting a floor
when you haven’t identified a workable plan yet. There are always at least
four corners, and rarely more than two doors. The odds are not in your favor.

~~~
shantly
I'm having a hard time following what you mean. Could you give some examples
of an irreversible decision that can be deferred in favor of some other
specific reversible one(s)?

~~~
hinkley
Interesting. You know, I would’ve sworn I had a pat answer to this question,
but it turned out I had to think about a little bit.

They say that some of the most rewarding interactions for teachers are the
ones where they learn something, not jus the student. Every once in a while I
get an example of that in real life.

So what are some examples? Programming language is often difficult to change.
This is sometimes listed as a pro for microservices. Because I get to change
my mind for every new area of the app, which makes it cheaper to reverse
directions.

The most obvious answers that I have are load balancers and external caches. I
shouldn’t have a big knockdown drag out argument over haproxy vs nginx. Now, a
load balancer is almost a given. It’s possible that someday in the future,
someone will invent an SMP machine with 256 cores that gets some economy of
scale by running a whole website on two machines. It’s easier to reduce the
number of machines behind a load balancer than it is to add a load balancer to
a mature product. So put one in, but don’t fight about which one. We don’t
know if we need haproxy features, or if we want paid support from nginx now.
Just flip a coin and move on.

Similarly, external caches are usually easier to turn off than internal ones.
With internal caches, people start to pass around IDs instead of objects,
assuming object lookup is “free”. It becomes integral to the information
architecture. A rat’s nest of lazy and duplicate lookups. External caches are
cheap but never free. Access tends to leave bigger footprints in the code. And
there’s some small hope that you can get a direct lookup down to a small
multiple of the cache lookup time if it really becomes necessary.

Database architecture is another big one, for certain dimensions. Going with
Oracle is hard to take back. MySQL vs Postgres is smaller. KV store versus
MVCC SQL database is also harder. For a prototype it might make sense to pick
one that is obviously a placeholder, like SQLite, until you know what your
customer’s needs really are. Do they need audit trails? Are they addicted to
graphs? Multitenant security? On and on. You can stave off fights with SQLite
because it’s effectively a promise to revisit this later.

------
pgm8705
I couldn't agree more. For 5 years prior to 2019, I would routinely get
excited about building a project. Despite being an experienced Rails
developer, I'd spend hours upon hours researching and learning all the latest
and greatest tools and languages. I did not even get close to shipping an MVP
in all those years. In 2019 I realized enough was enough and started building
my ideas with Rails. It has been a joy and I'm close to having my 2nd project
up and running.

------
rooam-dev
Imho it's far from "just". The advice works for short lifespan products and/or
single "builder" and/or when requirements don't change much.

Getting the product fast out there is not enough. It's more important to make
changes fast, to allow product be shaped and built further.

It should be a balance (see "golden goose" tale). If you have a team of
"builders", than tooling becomes even more important, 1 person's extra effort
will make others more efficient.

"Just build the product" sound like a consultant motto that ships by
specifications, but only that. You could "just" build a product that needs 1
hour to be deployed.

Edit: I would say a better advice to "builders" would be just focus on the
scope, it's very easy to get exited and overengineer things.

------
mooreds
Whenever someone asked me what language or framework they should use to build
their project, my default answer is "whatever you are familiar with". The
honest truth is that for the vast majority of applications I have seen, the
risk is in building the wrong thing or getting wrapped around an axle trying
to figure new technology out, not choosing an old boring technology that won't
scale.

~~~
coffeefirst
And even then, your odds of handling scaling issues with things you're
familiar with are a lot better than with new things.

------
gprasanth
It's fun the first 2 times you do it as you like. Then you start thinking
about doing it right.

Then you start thinking about building stuff right from the beginning which is
basically intelligence you've gathered.

It takes finesse to craft things quickly but with quality.

Bias to do stuff quickly is very hard to let go off. Doing things in an
organised way has its value. Basically if you're not going to rewrite
something in the next year, do it right now. Otherwise you're just borrowing
time from future.

Short term hacks vs long term meaning.

~~~
marcosdumay
After you learn some lessons, it's tempting to check any action against all of
them. But that slows you down, the more experience you have, the slower you
will be. You don't want to do that either.

Anyway, it is very hard to stay away from both extrema. It requires constant
self awareness, and even more learning, of the hardest kind where you are
required to feel stupid all the time.

------
vjeux
If you are interested in going further down the pit, you may want to consider
joining an infrastructure team at a bigger company. This way you are able to
use your skills at the bottom of the pit to enable many more people to build
the product faster.

------
onebot
The point isn't "just start coding". The point is to focus on the
product(customer development and all) and not the tools/technologies to build
the product. I have seen many more focused on the latest and greatest stack
instead of using the tools they are already good at.

~~~
hinkley
As with most things in our field, the opposite of a bad thing is also a bad
thing.

When stuff is new, people have a higher tolerance for repetitive, error prone
things. For tedium. For bullshit. But over time a portion of your team will
lose patience. Their allergy to bullshit will return. These are many of the
same people who pull off productivity gains, hard performance fixes, who fix
hard to find bugs. Who prevent whole classes of bugs. If they don’t get to fix
the things that bother them, they will go somewhere where they can.

What will be left are the status quo people. If you don’t have your project in
a good shape when that happens, it never will be. You will have achieved
mediocrity.

If things are good and the allergic people are still pushing? At some point
it’s appropriate to move on. Just make sure you know for sure things are good
and aren’t just listening to feedback from the status quo folks.

~~~
jimbokun
> If you don’t have your project in a good shape when that happens, it never
> will be. You will have achieved mediocrity.

But most times the alternative is not mediocrity, but no viable product at
all.

------
zackmorris
I've been messing around with notions like radical inclusion and radical
transparency, so just want to add that this article resonated with me. I've
reached the point where I have all the tools in the world at my disposal and
haven't gotten anything done in over 6 months. Most days are a complete loss:
nothing accomplished, just treading water till the next day, hoping something
will change and I'll get my motivation back.

It's weird to be writing this now, since I started out so ecstatic about tech
that I annoyed people with my enthusiasm 20 years ago. But no more, now it's
the opposite. A sense of loathing and dread when I think about writing code.
My friends say maybe I should get out of programming, at least for a while.

So not really sure what to do now. I want to build things now more than ever.
But it's mostly along the lines of building stuff in the real world. Writing
code in any form lowers productivity by a factor of 10-100. Sure it's great
once it exists, but teasing solutions out of the aether is like trying to
sketch with Photoshop. The more advanced it gets, the further it strays from
pencil and paper. And I just don't have the stomach to bash my head against
the keyboard for hours trying to do the simplest things anymore. I feel the
loss of time weighing on my shoulders more than the sense of accomplishment.
Without the "aha" feeling, coding loses its luster. Without passion, coding
may not even be possible.

The best thing I could do for myself is forget the last 20 years. But I don't
know how to do that. Any suggestions?

~~~
cosmodisk
Get a job( even if it's for a few days, evening, weekend or part time) in some
completely unrelated field. It's fascinating how much you can discover when
you step out of the world where a standard notion is to either automate stuff
or to make some smart,yet complex solutions to most problems.

------
jagged-chisel
I would. And honestly, I can. But I'm not the owner/maintainer of the full
pipeline that gets The Product into the hands of the end user. I write the
code. Someone else wants it stacked in a specific way that matches the
production environment.

But the path from my desk to that environment changes twice a quarter. And
each change requires me to change something in the stack of tooling. Why? I
honestly don't know. I suspect it's some kind of incompetence: employee
turnover means less-experienced folks take over, and they don't know, or can't
be bothered to learn, the previous guy's stack. Or the stack is chosen by the
new Senior Middle Manager every time that position changes because he's not
familiar with that last iteration of technobabble.

Whatever the case, it's really because the company has become too unwieldy,
hiring too many technology employees, and far too many business folk. You want
me to stop "playing" with tools? Let me get deep knowledge on one set and stop
getting new ones. Let me actually build something instead of forcing me to
navigate the org structure every time "one inconsequential end user" wants to
make a change to a feature.

------
XCSme
This rings a bell or two. After spending years of creating projects with
Webpack and wasting tens of hours on configuration, I just started my new
project with parcel, where I just run "parcel index.html" and I'm done. I had
fun configuring all the stuff before, but now I just need to get the work
done.

------
tuldia
It saddens me to see people growing a business and having to make tradeoffs
due to hosting costs or trying to catch up with new tech.

My (opinionated) take on this if you are just starting a new business:

    
    
      0. Lay your foundation on something that is battle tested and well supported.
        
        Rent/buy a real computer (dedicated/root server), not cloud.
        Use software that is already included in major/stable GNU/Linux distributions.
    
      1. Build your stuff.
        Get used to writing things.
        Beware tech news.

~~~
mlcdf
> Rent/buy a real computer (dedicated/root server), not cloud.

What brings you a dedicated server that a VPS running Debian for example
doesn't?

~~~
tuldia
Better raw performance, low latency, etc

------
foxfired
There's been a change in sentiment here. Just build the Product is still neat
advice that needs to be repeated. Sometimes we get too caught up with the
plan, perfectititis, and only ever fantasize about building it.

In contrast, the more experience you get building products, the more your
repertoire of problems grows. You start to realize that the code is only one
part of the problem. Interacting with people is what makes or breaks your
product. So, you plan better, you meet the right people to talk to, you figure
out when to outsource and when to do things yourself. You take more time to
build stuff.

But, you can't do any of that unless you first build a product.

------
flagpack
Thanks, just what I needed. Your use of those two paragraphs was very
effective.

~~~
davnicwil
Thank you - and really glad it was useful

------
marknadal
I love this quote from it:

"Build features, not toolchains."

[https://www.urbandictionary.com/define.php?term=webpack](https://www.urbandictionary.com/define.php?term=webpack)

------
ken
The first example I thought of was on the C=64, with assembly language. The
second was on MS-DOS with C++ and assembly language.

> Creating something useful using nothing but the raw materials of ideas, with
> essentially limitless possibilities, with your own creativity as the only
> physical limit on what's possible.

As soon as there's an OS and compiler and runtime in between me and the
computer, this all goes out the window. It's an artificial world with pre-
built materials, and limitations everywhere you turn, and 99% of the ideas you
work with will be someone else's, and how to fit in with that.

My view of a computer in 2020 is all about the tooling, and I spend the most
time on that, because everything I touch is someone else's tooling. The
"endlessly fascinating process" that hoodwinked young me into software no
longer exists.

I didn't pick up the "C=64 Programmer's Reference Guide" because I mistook it
for a business manual, or even because I wanted to build Amazon.com and just
needed to write the infrastructure first.

~~~
jdsully
The CPU’s instruction set and machine architecture are just as artificial. Try
FPGAs and you can really experiment with non von neumann machines.

But even that is artificially limiting. The tooling makes it nearly impossible
to build fully asynchronous designs.

~~~
ken
That's technically true but I think it misses the point. A CPU (at least an
older one) is simple enough that it can be fully understood by one person. It
was probably designed by a very small team. If you want to know if something
works, you don't have to read thousands of pages of documentation. You can
just try it. Nearly any combination of operations you put together is going to
do _something_.

None of that is true of the big complex language/library/framework/OS stacks
we have today. Most of my effort programming today is on something simple to
describe in words, but complex to encode in the language's type system, or the
framework's classes, or the OS's security model.

I feel that Lisp is the closest I can get to those early systems I grew up
with. It's based on symbols rather than bytes but the flexibility and
coherence is the same.

~~~
jdsully
Today we have different systems for different needs. You can use an
interpreted language like Python to get simplicity or you can use something
like Rust where a program essentially doubles as proof of correctness. Strong
typing is really about managing complexity as the program grows. This was
never an issue on 8-bit micros because there just wasn't that much room to
grow anyways.

------
iliomadfear
At the risk of seening facile, the "just" the title resulted in my being
hostile to the article. But, to try to be fair, I read it.

After completing the toughest gig of my professional life to date, "just build
the product" as an instruction/conclusion feels both useful and flip.

In my head, I have an idea for a product. Sod all money in it. But as useful
tool for something I care about, the "just build it" mentality fits.

However, in the roof-over-head world of making something useful for an
enterprise customer "just build it" feels trite.

I went in to as a software consultant/developer to a fairly non IT literate
organisation and was tasked to deliver to their specs. The big and costly
challenge was to discover the product. To understand and challenge their
specs, see the gaps, refine the UX and deliver. In my naivety, I thought the
the customer would be receptive to this approach. Turns out they were - but
only because I shouldered the cost of doing so. A massive learning experience
for me. The customer got a product that exceeded their expectations - but, for
a fixed price gig, commercially a failure for me.

I wouldn't change my willingness to jump in this time around, but I won't
repeat it - and would now walk away early from a customer that thought they
had the solution all figured out (as opposed to having the problem figured
out). In this circumstance "Just build the product" feels trite and self-
indulgent. Clarity on what to build is hard earned. And the opportunities that
iterative development affords to a a software development organisation are a
hard sell to one whose core expertise lies outside IT. Possibly a failure on
my part, certainly room for improvement on my part.

------
ChrisMarshallNY
I've been working this way for thirty years. In fact, I can't remember ever
working on something that wasn't designed to ship.

Even my test harnesses are fully-qualified applications.

I remember a manager once saying "The number one feature of this product is
'SHIP.'"

Because of the nature of the companies in which I've worked, we always worked
backwards from "SHIP."

------
overcast
Sure, if the product is something you don't intend to make a business out of.
Otherwise, you should be doing your homework ahead of time, and seeing if this
is something people are actually in need of. Most ventures I've worked on have
been derived from the immediate needs that I found not being covered in my day
to day life from others.

------
solarized
Torvalds are great examples to this.

    
    
      1st. build linux for the first project.
    
      2nd. build git to maintain linux.
    

Build the product that useful !.

exercising and useful is better not just for you. but also to other peoples.

------
kareemm
This is the right advice if you want to nerd out on technology. But my
experience suggests[1] that if you want to build a __business __it 'll be
cheaper to validate problem/solution with phone calls and mocks / designs
before writing code.

This is because:

* It's cheaper to make changes before code has been written

* A functioning product isn't the best sign that you're making progress - paying customers are[2]

Don't get me wrong. I like to write code as much as the next guy / gal. But
I've made the mistake of writing code first. And I've worked with clients who
- despite my best attempts - decided to forego validation to build a product
that they spent a lot of dev dollars on to fix once the market met it with a
trickle of interest.

1- [https://uncog.com/archive/v2/why-only-fools-write-code-
first...](https://uncog.com/archive/v2/why-only-fools-write-code-first/)

2- [https://uncog.com/archive/v2/how-to-get-paying-customers-
bef...](https://uncog.com/archive/v2/how-to-get-paying-customers-before-you-
start-writing-code/)

~~~
kyllo
I read it differently--this is not targeted at founders trying to validate a
business plan, it is targeted at engineers whose job it is to build the
product, and he's saying to quit fiddling around with your tools and focus on
building the product--which is more fun anyway.

"It's important to learn how to use your tools well, but once you have, stop
prioritising that. They're good enough now, you know how to use them. Don't
get trapped in this local maximum of optimisation. Go and build stuff."

~~~
bluedino
10 years ago, I wanted to learn Ruby on Rails, so I bought my first MacBook
Pro. Just grabbed it off the shelf at the store.

I got my first software development job, and everything was great. I thought
it was odd that the other guys didn't know much about Macs (and didn't really
seem to care), so when they'd upgrade the OS I'd have to fix everything for
them, or they'd have issues with gems etc.

I started buying every MacBook as they were relased. Installing beta software,
upgrading the RAM and HD just because I could. Spending countless hours
reading reviews, posting on forums...

The other guys just wrote code. Eventually I got tired of keeping up with the
crap (or maybe I just got older) and now I crank out code on my far-from-the-
latest MacBook, running Mojave. _shrug_

It was fun stuff, but I could have spent that time (and money) more
productively.

~~~
shantly
It's really funny to me that someone could get excessively sucked into
tinkering with and "nerding out" over Macs, the desktop/laptop platform that's
by far the _least_ inclined toward that. Usually stories like this start on
Windows or Linux and end up on Macs precisely to minimize time & brain space
lost to tinkering and esoteric platform knowledge just to keep things
basically working OK, as the appeal of that sort of thing wears off.

I don't mean that in a bad way! It's just one of those "huh, so many different
experiences out there, who'da thunk it" things.

~~~
chefandy
I've used Windows, Linux/FreeBSD, and MacOS (and heck, even Solaris)
extensively as desktop OSs. Windows is _only_ better than for MacOS for
tinkering if you're not comfortable using the command line.

------
pezo1919
Yes and no.

I'd say if you have a set of features and a toolchain which enables you to
build them then ofc go for it.

However that's not my usual experience with any of my projects even personal
ones.

The thing is I don't know what I'm going to build, in the contrary, I am aware
it will take several iterations to figure it out. Because of that I have to
check out what is "out there" in the ecosystem to make sure I can change
directions sometimes if I want to. I want to maximize my freedom in that
niche. Because of that every time I have some additional information about the
whole project (in which features come and go) it's an option to step back and
reevulate existing possible solutions in my mind and go do some further
research when necessary.

My experience is when parts are not thought out in a project then they will
slow the entire workflow down over and over again.

Just build or just not to build: I think this is a wrong question. When start
to build & how/what to research are much better I think - and with real
examples its much more useful I think.

Eg.: I'm totally done with relational and document databases. To me it seems
both suck hard so lately I am investigating graph dbs. No, I won't start a new
project until stupid rigid schemas / migration problems / schemaless
weaknesses (dupe) won't just go away.

Maintaining old shit is enough for me I really don't want a new broken system
as technical/real life debt.

Ofc you can go out and build pages with jquery which do generate tons of money
for you, but others will be able to do the same when they've figured stuff
out. What then?

------
beat
A lot of discussion of best language, etc, is just bikeshedding. (See
Parkinson's Law of Triviality) We talk about technologies we use because it's
easier and safer than talking about the actual _product_.

------
ozim
Yar, funny those people who comment "no never build the product first, do
marketing and find if there are customers for it", don't read the page.

"davnicwil" is, guess what -> "Open source" "Freelancing" "Consulting"-> motto
"I turn ideas into products"

He is just trying to sell his services to people who want to build the
product, and guess what he advises them to do that, and that is his page. This
is not some holy grail advice, get some context and step back people.

Ok I know everyone is reading only headlines here anyway...

------
randomsearch
This is exactly the opposite advice I would give to anyone starting a company
- avoid building software at all costs.

~~~
tylerrobinson
I don't think the article is saying "just start coding", it's saying "when you
code, use what you know instead of working on the tooling".

------
johnvega
It is great if it succeeds and useful, but if not, it's usually a great
learning experience.

------
shripadk
Thank you! I needed this!

------
quantum_state
AAbundant past examples have shown if a business “just build the product”, it
will soon does not need to build any product any longer ... since it will be
belly up :-(

~~~
quickthrower2
Yes: Just research the market first.

