When to Stop Building and Start Showing It to People

The first MVP I ever shipped had 47 features. The users only cared about 3 of them. I built the other 44 before a single person had touched the thing, because every one of them felt necessary while I was alone with my editor and nobody could tell me otherwise.

Stop building the moment the product does one real thing end to end, and put it in front of a real person that same week. Not when it is good. Not when it is complete. When one path works from start to finish — a user can come in, do the single thing the product exists to do, and get a real result out the other side.

Everything you add after that point, before anyone has used it, is a guess. Some guesses are right. Most are the 44 features nobody asked for. You cannot tell which is which from inside the build, and that is exactly why you have to get out of it.

The tell is that you keep adding things nobody asked for

There is a specific feeling that shows up when a product is technically ready to show and you keep working on it anyway. It does not feel like avoidance. It feels like diligence.

You are adding settings, edge-case handling, a nicer empty state, a second way to do the thing you already built one way to do. Each task is real work and each one is defensible on its own.

The pattern only shows up if you ask where the tasks are coming from. When a real user hands you the next feature, you can name the person and the moment. When you are generating the list yourself, at your desk, from what the product "should" have — that is the tell.

You are not building toward a user. You are building away from the day you have to show it to one.

I know the feeling because I have a product in my graveyard that is made entirely of it. A project management tool I built kept growing more features because each one felt like it made the product more complete. It made the product more confusing.

Users opened it and could not find the one thing they came to do under everything I had piled on top. I had mistaken volume for readiness. The tool was never short of features. It was short of a reason for anyone to stay, and no amount of building was going to produce that from the inside.

Polishing is safer than shipping, and that is the problem

Shipping is the moment you stop being right in theory. Up to that point your product is whatever you imagine it to be, and the imagined version is always working. The instant a real person uses it, that version dies. They ignore the feature you were proudest of. They get stuck on the step you thought was obvious. They want something you never planned for.

That is uncomfortable, so the mind finds reasons to delay it, and "it's not quite ready" is the most respectable reason there is.

Nobody argues with quality. You can polish for months and every day of it looks like conscientious work rather than what it often is — a way to not find out. The longer you stay in the build, the more you invest in a shape of the product that no one has confirmed anyone wants. Fear of pivoting is easier when you have not yet been given a reason to pivot, and staying in the editor is how you avoid being given one.

Building past "it does one real thing" does not lower your risk. It raises it. You are spending your scarcest runway making a bet bigger before you have any evidence the bet is good.

What shipping early actually buys you

RealEstateCRM is the counterexample I keep coming back to, because I built it the opposite way and it has been running in production since 2021.

The first version was not a CRM. It was a plain apartments database — a list of properties you could add to, search, and edit. That was the one real thing it did end to end, and I shipped it in two weeks, straight into the client's daily work. It was almost embarrassingly small next to what a real estate agency "needs." I shipped it anyway.

Then I watched them use it. Within days the real thing they were missing showed up on its own: they needed a customers database too, so the property list could function as an actual CRM instead of a catalogue. I had not planned that as feature one, or feature ten. Their usage handed it to me. That took another two weeks, and from there the product grew for months the same way — document management, a WordPress site integration, deal tracking — every addition coming from someone using the real thing and hitting the real edge of what it could do.

None of that was on a roadmap I could have written up front.

If I had spent those first two weeks building the customers database I assumed they wanted, I would have built it wrong, because the shape they actually needed only became visible once properties were flowing through the system with real listings and real people behind them. Showing it early was not a risk I took with an unfinished product. It was the mechanism that told me what to finish.

How to know you have hit "enough to show"

The line is narrower than it feels, and it is not about quality.

Ask whether one person can complete the single job the product exists for, from entry to result, without you sitting next to them. If yes, you are past the line and every further day inside the build is optional. If no, you are genuinely not ready and you should keep going.

Most founders are nowhere near that line when they think they are far from it. The 47-feature version felt like the minimum. Three features were the minimum. I could not see that while I was building, and neither can you, because the only instrument that measures it is a real person using the real thing.

You do not build your way to that answer. You ship your way to it.

The urge to add one more feature first is not a sign the product is close. It is a sign you already know it works and would rather not find out what a user thinks. Show it before you feel ready. Feeling ready is the last thing to arrive, and it usually arrives long after the product was.