Just Build the Product
davidnicholaswilliams.com
davidnicholaswilliams.com
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.
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.
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.
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
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.
I don't ask this critically. I am genuinely curious. I wonder about this a lot; there are so many languages that solve the same problems in slightly-different ways, that I'm always curious as to the motivations behind creating another new language.
So many amazing projects started as someone scratching an itch, often completely unrelated to the eventual product. And even if a project doesn't take off, if the goal was to get better at programming (and not marketing, project management, etc) it may be still be a success. Both forms of projecting have value. It all depends on personalities and where people are in their careers.
While I do sometimes get excited about learning a new technology, the most fun projects for me are where I already know all the tech required, and all the new ideas relate to whatever I'm building.
And I had assumed that would be the case for most people.
I see the differences between the two as:
1) Learning a new technology is kinda like reading a sci-fi short story to me: it's mostly about getting some interesting new idea, with the added benefit that it may apply favorably to my future work.
2) Building something new with known technology comes with the kind of unstilted, gratifying fun experienced when exercising well-developed skills in service of producing something. Often this comes with flow states; internalizing new concepts and practicing new techniques on the other hand are not ideal for this.
They both have their merits but to my mind, the second one is on another level, and I'd recommend to anyone using their fun projects only to learn knew things to try exercising their already established skills to build something they'd just like to see running, or to share with friends etc.
Edit: just to give an example: I had a lot of fun building this game where I learned no new technologies, and in fact had already built basically the same game 12 years prior (with different tech and far less knowledge). Instead I explored ideas related to the architecture that I thought might generalize, and enjoyed myself developing the algorithms and aesthetics that made the thing work: https://github.com/westoncb/under-game
I've been racking brain cycles the past few weeks trying to figure out how to solve this problem.
- Amount of dev time needed to ship an MVP
- Lack of a business partner
- Not having a pilot customer lined up
- Getting old
Those are some of the issues I see as a far bigger hinderance than any tech stack stuff. Shit, when is the last time (have I ever) tried doing a no-code MVP. Not always possible, but I'm sure somewhere in that stack of unfinished projects I could've come up with a no-code or very limited code MVP...
He spends his energy lamenting over the "right" tools, to the point that he considers it a moral decision and part of his identity. He has trouble keeping work, because he's always looking for a company that uses the right tools instead of building the right thing. I'm sick of him lamenting "I could never work at [x] because they use java, and I never wanna see another NPE".
I personally constantly restart side projects, with different languages, or tools, or whatever because I read something about why {language, tool, whatever} is better than {what I was using}, so sometimes, it nice to remember that if its not a learning process.. it might just not matter :)
Ironically, this kind of meta over-analysis is one of the major reasons why things don't get done.
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.
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.
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.
Ah, the solid, dependable base that is the requirements!
I'd question the reason to wait. Shove it out the door so you can learn. I say that because I'm a professional and I've seen many projects fail before seeing a single user. I've never seen insurmountable technical debt grind a business to a halt. Not once.
I’ve seen this happen more then once. The best and brightest tire of the crap and leave to go do other things; and those who stay erode the culture into a cesspool of negativity. Sure the business trods along for a while but often the products just enter a phase of slow death and irrelevancy. At some point there’s some kind of private equity acquisition or transaction which just temporarily delays the inevitable.
To be clear, I’m not arguing for “strict requirements”. Just that the professional engineer is who needs to distill the chaos into clear and ready action. And, that “just ship it” can sometimes come with cost.
These articles usually come across as flippant. They are written from a small business or early phase/unproven startup point of view. Sure, don’t waste all your time tweaking tools, but at the same time, make sure you’re not shooting yourself in the foot because of the 50 kludges put in place that overlooked security or performance considerations.
I guess this is just a way of saying “there is no silver bullet”. “Just ship it” doesn’t always work.
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.
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.
Anyone claiming there is a clear answer to these questions is deluding themselves. Tactically, the best weapon is to recognize your own weaknesses, and it seems to me that engineers often have more of a bias towards performing tool and technology analysis and research in the name of avoiding the hard and often humiliating task of shipping software that users will almost certainly hate in its earliest versions.
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.
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.
But most times the alternative is not mediocrity, but no viable product at all.
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?
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.
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.What brings you a dedicated server that a VPS running Debian for example doesn't?
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.
"Build features, not toolchains."
> 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.
But even that is artificially limiting. The tooling makes it nearly impossible to build fully asynchronous designs.
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.
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.
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."
1st. build linux for the first project.
2nd. build git to maintain linux.
exercising and useful is better not just for you. but also to other peoples.
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...
2- https://uncog.com/archive/v2/how-to-get-paying-customers-bef...
I really suspect that the lean startup method belongs in the early web era when there was a ton of low hanging fruit with simple market research and simple MVPs. All that low hanging fruit has been picked. Today it's pick your brutally hard problem and iterate for 1-2 years before you get a MVP that you can test.
Just build the product - the purest most minimal version you can. I mean be judicious with the knife, and slice like it's going out of style. Accept it - you're throwing out 100% of the code eventually - be fine with it; it's not ideal, but you'll ship and be live. Add the analytics you need - test hypotheses. Reach out to people who drop in and drop off, they're more valuable than features.
Don't agonize over "this isn't done", "this isn't perfect" or "it needs X to be useful". Get it out, charge for users, and you'll build a sustainable business, or it will fail quickly. Sure, this may not be VC sexy - but you know what, you can build product quickly, validate or toss and idea and move along or improve, based on feedback.
This ships. It ships repeatedly. It's not perfect, it's not awesome, but it works, always.
Ask them to pay you based on the mocks. If they say no, ask why. If they say yes, take their money and give it back in N days if you haven't built your MVP. I've done this BTW - it works.
> You don't find out who will actually buy until they try a functional product.
You'd be surprised how many people have gross business problems that some well-placed code would solve and they'd be thrilled to pay you for it because the other options suck.
If you don't have something to sell me, now, why are you asking for money? Am I an investor? No? Come back when you have a product. I'll probably still say no because I won't expect your business to last very long, but you'll be 100x closer to a "yes" than you are now, which is about as far from it as you could possibly be. Is this an unusual attitude?
"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."
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.
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.
Examples include circuit board layout programs, finite element modeling, any engineered hardware product, entertainment (like computer games), or anything other than pure business, really.
"Don't write code" really means "prototype first for your potential users". So if your code won't have users/customers, then write away. But hardware and entertainment can absolutely have low-fi cheap prototypes.
This approach is designed to elicit learnings to make a better product that's cheaper and faster to build. Of course you can write code first, but my experience suggests that that's a slower and more expensive approach.
1) working on tooling 2) building the product
Of the two, which do you prioritize?
The article makes the case for #2.
That's it. Nothing you say contradicts what the article is saying, nor does it add to what the article is saying.
Like, taking a rough guess, I wonder if there aren't as many successful startups, as there are successful writers. But no one takes those guides to writing a successful book quite as seriously as those guides to running or starting a successful business.
Tangentially, recently this motivated me to build a platform for validating problems by making people post their problems and even validate startup ideas as solutions to those problems[2].
This is basically an attempt to gather more information before you act. In principle, that's an Obviously Good Thing. But you have to question whether that information is actually as conclusive as you want it to be, and whether you're changing the outcome by observing it. There's two problems with the information you gather by making phone calls and showing mockups/designs:
1. Mocks/designs only communicate a fraction of the product, and often the parts that aren't visible in mocks/designs are the most valuable parts of the product. Speaking in vague terms: I'm working on an app where the main value is that it calculates actionable numeric values that users typically calculate in spreadsheets. The UI is certainly a selling point, but users aren't going to easily understand the connection between the new UI and the old spreadsheet formulae without playing with the actual product. Phone conversations are likely even less communicative.
2. Communication is a two-way street: releasing early allows you to get information from your users, but it also leaks information to your users, which may not present the image you want. Kickstarter has shown that with good enough marketing you can get paying customers with literally nothing. But you can also burn customers so they never want anything to do with your product ever again. There are numerous high-profile failures-to-deliver that have killed not only products, but the reputations of individuals and companies. But failure doesn't have to be that catastrophic to lose customers permanently: all that has to happen is for someone to pay for your product, find it a bit lackluster, and decide to cancel their subscription. That user is worse than a non-user, because they are never going to be a user again, and might tell others about their experience. Short term success not only isn't an indicator of long-term viability, it can cause long-term non-viability.
Sure, it's cheaper to validate problem/solution with phone calls and mocks/designs, but you get what you pay for.
The best strategy probably lies somewhere in the middle: code a minimum viable product, but really make sure it's the minimum, and really make sure you think it's actually viable. A good compromise might be to release a discounted beta for select users--that lets you get feedback from paying customers up front, but also sets expectations so that users don't get the wrong idea about your product before it's mature enough for a real release. It also limits the exposure, so even if you burn a few beta users, you don't burn your entire potential user base.
Even this sentence is a perfect tool for validating the market: I have no idea if the product is for me! ;-)
(I get that you may be keeping your product’s specifics vague here, but by doing so you’ve provided a contrived example of how a simple description of the product itself can help find information about the target market. I have no idea if I’m in your target market, for example, so if I’m supposed to be, that’s a problem.)
You probably are my target market--it's a pretty broad demographic. But if I showed the product to you now, you'd probably be unimpressed and forget about it, which probably loses you as a customer forever. Better to wait another few weeks and give you something that actually solves a problem you actually have.
There's only one chance to make a good first impression.
I'll write something (or even just put together drawings) for someone and the first review of something like really light prototype / sketch where I get direct feedback from decision makers and/or users is FAR MORE TELLING about where things are going to go than anything else.
It's amazing how much pivoting can happen there.
Maybe I was and still am a complete idiot. But I think a lot of people would be like me and just assume that lots of people want X, Y, and Z -- so go out and build the thing, and then realize nobody wants X or Y, and no one is willing to pay for Z.
I started doing financial models when I get an idea. What I always find out is -- even in my wildest dreams -- these ideas wouldn't pay more than my current job.
Granted, I make a lot of money. But I think the vast majority of people on here make more money now than is reasonable to believe their business could ever make, if everything worked out.
Most products are mainly built by people who face that same problem their app solves. This gives them a reason to build it. As worst, it's used internally. At best, it's a side hustle or much more.
> Ok, now -- what language was it written in? Which editor did you use? Use any open source libraries?
> In the best way? How long did it take to run the build? Was it easy to debug?
> Was it as memory efficient as it could have been?
> Were you building it on a really slick machine? What was your keyboard set up?
This article is about your improving your life as engineer, questioning your technical way of working is how you grow, but not always the way forward. Search this article for the words "company", "business", "startup" or "customers" and you will find 0 hits.
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?
"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...
It is advice for engineers to focus on the utility of the thing they are making for other people, rather than focus on the toolchain that allows them to build the thing.