The Smallest Honest Version: How I Decide What to Build

When you build alone, the bottleneck is never typing. It's choosing. There is always a longer list of things worth building than there are weeks to build them, and the difference between a product that ships and one that quietly dies is almost entirely a difference in what got left out. So the most important skill I've developed since going independent isn't a framework or a faster way to write code. It's a way of deciding what not to do.

My filter is a single sentence. If I can't name the annoyance a feature kills in one plain sentence — no "and also," no "which enables" — it isn't ready to build. The one-sentence test isn't about brevity for its own sake. It's a forcing function: a feature you can't describe in one breath is usually two features wearing a trench coat, or a solution looking for a problem, or my own boredom dressed up as a roadmap.

The smallest honest version

Once a thing passes the sentence test, I don't build the version I'm excited about. I build the smallest version that's still honest. "Honest" is doing real work here. The smallest dishonest version is the demo that works on the happy path and falls apart the moment a real user does something slightly unexpected — the thing that looks finished in a screen recording and isn't. The smallest honest version is narrower in scope but complete in trust: it does less, but everything it claims to do, it actually does, including when the input is messy and the network is bad.

On CapitalGains, the honest version of a calculator wasn't more inputs and more scenarios. It was fewer scenarios, each one correct to the dollar and tested against real tax rules, because a finance tool that's confidently wrong is worse than one that politely admits it doesn't cover your case. On VoltExam, the honest version of a new vertical wasn't a thousand auto-generated questions. It was a smaller set that survived evals, because a learner who hits one wrong answer stops trusting all of them.

A smaller thing that's true beats a bigger thing that's mostly true. "Mostly true" is just a bug with good marketing.

What I cut, and how

Cutting scope sounds like discipline. In practice it feels like loss, every time, which is why most scope creep is emotional rather than strategic. The trick that works for me is to separate the two questions people usually answer at once: "is this a good idea?" and "is this the next thing?" Almost everything is a good idea. Very little is the next thing. I keep a list of the good ideas precisely so I can stop arguing with myself about them — writing it down is how I give an idea a respectful no.

Applied AI has quietly raised the stakes here. When the cost of producing a feature drops toward zero, the temptation is to build more of them, faster. But cheap to build was never the constraint — cheap to maintain, support, and be right about is. Every feature I ship is something I personally have to keep correct at 3am with no team behind me. That accountability is the best scope-control tool I own. The model will happily generate the feature; I'm the one who has to mean it.

Why small wins

The reward for shipping the smallest honest version isn't just a calmer codebase. It's that real usage gets to argue with you sooner. A narrow thing that's actually in someone's hands teaches you more in a week than a broad thing you're still polishing teaches you in a quarter. You find out which of your good ideas were the next thing, not by debating it, but by watching what people reach for. Build small, ship it true, and let the product tell you what to build next. That loop — not raw output — is the whole advantage of being able to move alone.

Arun Jalota is a Technical Director in Toronto leading a 12-engineer mobile team and driving AI tooling adoption. Reach him at arun@arunjalota.com · LinkedIn · GitHub.