High quality code comes much later

The plan is to talk to users, work out what to build, then go and produce a high quality first version with good architecture and decent performance and minimal bugs and iterate from there. That plan is wrong.

If you believe you can build the right product from the outset and then refine it by talking to people, you’ll end up with a garbage product. Not because the code will be bad but because what good architecture even looks like depends on the feedback you haven’t collected yet and so does what usable performance means and so does which parts need to be reliable.

You have to get something in front of users as soon as is humanly possible. If the thing you show them is well architected, has few bugs and performs nicely, then you’ve already spent too long on it. That sounds like an insult to careful work and it’s really a statement about what the early version is for. It exists to find out whether anybody wants this. Every hour spent on anything beyond that is an hour spent on a question you can’t answer yet.

First time founders find this really hard to accept and the reason is understandable. They’re frightened of losing potential customers by showing them something bad. What they should be frightened of is spending their time and their runway building the wrong thing which is the failure that actually happens and the one that can’t be recovered from.

There’s every chance the first version you show people is completely wrong. Not slightly off. Wrong in a way that means the next version shares almost nothing with it. When that happens, the quality of the code you wrote makes no difference at all because none of it survives and the six weeks you spent making it solid were six weeks of runway spent on a thing that got deleted.

That’s the trade nobody wants to look at directly. Good code is an investment in a thing continuing to exist. Early on you don’t yet know whether it will so the investment is a bet placed before the odds are visible and most of those bets lose.

If you’re focused on writing good code from day one then you’ve got the ordering wrong. High quality code comes much later, after you know what the thing is and after there’s a reason to believe it’ll still be here in a year. At that point quality stops being a cost and starts being the thing that lets you move quickly which is the argument its advocates make and which is entirely correct at that stage.

The mistake is applying it to the stage before, where the same discipline that makes a mature product fast to change makes an unproven one slow to discard.

The useful test, if you’re not sure which stage you’re in, is to ask what happens if you throw the whole thing away next month. If that would be a relief because you’d finally know what to build instead, you’re still early and should be moving faster. If it would be a disaster because people depend on it, you’re past that point and the careful work has started earning its keep.

None of this is licence to write badly forever, and the founders who use it that way end up with a different failure eighteen months later, buried under something nobody can change. The claim is about ordering. There’s a moment where quality starts mattering enormously, and it arrives after the thing has proven it deserves to exist rather than before.