Know When to Stop

One startup mistake that feels relevant right now is overbuilding. Overbuilding is largely a function of how costly that next commit feels. At the time, we only had human engineers, so at least we had wage pressure. Today’s coding agents have driven the marginal cost of one more commit to nearly zero on a relative basis. It won’t stay that way forever, but it’s that way now.can you

At the time, we had a super talented engineer, decent runway and a small group of excited customers.

Sounds great, but in reality it fostered many of the ideal conditions for overbuilding. I had effectively sealed our team into an engineering loop with early customers, believing this would lead to greater success. We shipped like mad. And on some dimensions it worked: superfan conversion rates were above 10% and time-in-app approached 15 minutes. But that vacuum killed us: we overfit for a subset of biased customers mostly because that next commit came quickly, instead of slowing down and validating the broader thesis.

This isn’t uncommon. I was recently talking to a startup founded by an entrepreneur with a prior successful exit. The consumer product they’re building is impressive: it feels cool, powerful and well-designed. It’s also trying to be so many things at once that it’s hard to describe what it is and who it’s for. I suspect the founder’s ability to self-fund afforded these indulgences. Having runway simulates success, but it’s not success at all. When you’re gasping for air with limited engineering capacity, you tend to build what real users need right now.

Of course overbuilding happens for many reasons but the result is that you feel like progress is being made when it’s not. This usually develops during the period when pressure for progress is extreme.

In any case, I should have been more aware that there are two signals to any investment: customer demand (yay! we’re being responsive) and customer uptake (but did anyone use it?) Answering demand is seductive because you’re satisfying customers…the essential job of a company. Plus the team feels responsive and productive. But uptake is more important: did it move acquisition, engagement, or willingness to trial?

Honestly I’m still surprised by how easy it became to avoid looking closely at the usage data. Nobody really wants to discover that months of work produced little value. Once you’ve sunk enough time and energy into something, it becomes emotionally easier to defend it than to be honest.

I still believe in co-engineering, but customers ought to be grouped as a cohort for a specific phase of a product, not as drivers of the roadmap. And roadmaps should have one-way success gates defined in advance. If a feature doesn’t hit its uptake target, don’t advance until you understanding why.

Looking back, I think we shipped the true heart of our thesis nearly three years in. By then, it was too late.

I’m going to end here, but before I do it ought to be obvious the parallels to what’s happening in agentic coding. I’ve ‘written’ nearly 40,000 lines of code in the last two months, mostly through pair-programming-style chats with Claude and Codex. Every single time Claude has the next bug, feature, Linear ticket, plan, nudge or extension of what we’re working. And I’m always intrigued because these little critters are summoning my ideas into existence for free, basically.

Then I remember that reality works hard to confuse you. Progress and motion can look identical. Knowing when to stop matters more than ever.