Stop Capping Your Build. Start Testing Demand.
Version-capping your build won't fix the real problem. A founder imposed a 'stop at v0.2.0' rule — but scope wasn't his issue. Evidence was. Here's how to test demand before you write a single line of code.
A founder on Indie Hackers just imposed a hard rule on himself: stop at v0.2.0. After two years of building things nobody used, he's decided that version-capping is the fix. Ship v0.1.0. Ship v0.2.0. Then stop. Move on.
It sounds disciplined. It's also solving the wrong problem.
A community member — the kind who's been through this enough times to spot the pattern — pushed back immediately. "Stopping at v0.2.0 is a rule about scope, but scope wasn't really your problem. Evidence was. A hard version cap just makes you fail faster if you're still not testing demand. You'll ship ten tiny things nobody wanted instead of one big thing nobody wanted."
That comment names something most validation advice misses. The trap isn't overbuilding. The trap is answering engineering questions for months before answering the product question. Version-capping addresses the symptom — too much code — but leaves the cause untouched: never testing whether anyone wants what you're building.
The Real Diagnosis
The community member put it simply: "answering engineering questions for months before answering the product question — is THE trap."
This is the pattern behind nearly every "I spent a year building something nobody wanted" postmortem. The founder isn't lazy. They're not undisciplined. They're solving problems they know how to solve — architecture, auth, deployment, performance — because those problems have clear answers. You ship code. It works or it doesn't. The feedback loop is instant and satisfying.
The product question — "does anyone want this?" — has no such clarity. You ask. You get politeness. You ask again. You get "sounds cool." You interpret silence as "they're busy." The feedback loop is slow, ambiguous, and emotionally uncomfortable. So you go back to building. It feels productive. It isn't.
Version-capping doesn't change this dynamic. It just shrinks the timeline. You'll still spend your v0.1.0 sprint on auth and database schema. You'll still interpret a friend's "nice idea" as validation. You'll still launch to crickets — just faster.
What Actually Needs to Change
The fix isn't building less. It's testing earlier.
Before you open your IDE, answer one question: what specific behavior would prove someone wants this? Not "they said they'd use it." Not "they signed up for a waitlist." Behavior. A stranger spending money. A stranger spending time. A stranger changing their workflow to accommodate your product.
If you can't name that behavior, you're not ready to build v0.0.1.
This is harder than it sounds. It means admitting that most of what you call "validation" is actually just collecting encouragement. It means sitting in the discomfort of not knowing, rather than fleeing into the comfort of building. It means treating evidence as the deliverable, not code.
The community member who pushed back on the version-cap rule framed it as a naming problem: "naming it out loud is most of the fix." Simply calling the pattern "engineering-before-product" makes it harder to repeat. Once you've named it, you can't unsee it. Every time you reach for your code editor before you've talked to a stranger, you'll know what you're doing.
How to Test Before v0.1.0
If you're going to impose a rule on yourself, make it an evidence rule, not a scope rule:
Before any code: one paying intent signal. Not a waitlist. Not a "sounds cool." Someone who has the problem, has tried to solve it, and is willing to pay or commit time to your solution. This can be a pre-order, a pilot commitment, or even just a stranger saying "I've been looking for exactly this — when can I use it?"
Before v0.1.0: five stranger conversations. Not friends. Not Twitter mutuals. People who have no reason to be polite. Ask them about the problem, not your solution. Let them talk 80% of the time. If they don't bring up the problem unprompted, it's not a real problem for them.
Before v0.2.0: one behavior signal. Someone used your MVP without you nudging them. Someone came back a second time. Someone told another person about it without being asked.
These are harder than a version cap. They're uncomfortable. They force you to confront the possibility that your idea isn't ready — before you've invested months of identity and effort into it. But that's exactly the point. The version-cap rule lets you preserve the fantasy a little longer. The evidence rule kills it early, when it's cheap.
The Pattern Has a Name Now
The Indie Hackers thread ended with the community member offering the simplest possible intervention: call it what it is. When you catch yourself building before testing, say it out loud: "I'm answering engineering questions because the product question is uncomfortable."
That's not self-flagellation. It's calibration. The founders who name the pattern are the ones who break it.
The version-cap rule comes from a good instinct — the recognition that something is wrong with the build-first default. But the fix isn't a tighter scope. It's a different question. Not "how much should I build?" but "what evidence do I need before I build anything at all?
