Why does my prototype keep stalling at eighty percent

Products stall at eighty percent because the last twenty is where every deferred decision comes due at once. It is a process failure, not a technical one, and it is almost never the developer's ability. The fix is deciding what done means before the build starts.

You know the shape of this already.

There was a demo. It worked. Someone clicked through five screens in a meeting and everyone agreed it was nearly there. That was four months ago. Since then it has been almost done. Always almost. A fix goes in, something else surfaces, and the thing that was two weeks away in March is two weeks away now.

Nothing has visibly failed. That is the worst part. A clean failure you can act on. This just sits there.

The last twenty percent is where the deferred decisions come due

The first eighty percent of a product is the part you can build without deciding anything hard. Screens, a rough data model, the happy path. All of it can proceed while the awkward questions stay open.

What happens to a half-finished form. What a user sees when the payment declines. Who owns the record when two people edit it. What the thing does at two in the morning when an API is down. Whether the export needs to match the accounting system exactly or approximately.

None of those are hard on their own. They are hard together, at the end, when each answer breaks something that was already built. So the last twenty percent is not twenty percent of the work. It is every decision nobody wanted to make, arriving at once, into a codebase that assumed they would go the other way.

The developers who leave products stuck at eighty percent are usually not bad developers. They just never had the discipline. They built everything custom, sharpened the wrong four percent, and small things piled up until nobody could point at what was actually broken.

That is the worst place to be. Not a clean failure. A thing that is always almost done.

It is a process problem wearing a technology costume

The truth underneath this is unglamorous. Building something that works is not really a technology problem. It is a process problem. Keeping things simple, using proven tools instead of inventing new ones, and planning for the fact that you will be wrong about something.

That last one is the piece people skip.

If you have built one product, you have a sample size of one, and everything you believe about how it goes is survivorship bias. If you have built hundreds you know something different. You know roughly what fraction of the things you are confident about today will turn out wrong, and you leave room for it in the plan instead of treating it as a surprise when it happens.

We built a product for a vet marketplace that had been in progress for two years. Thirty thousand dollars in, stuck around eighty percent, one change landing a month. The rebuild took weeks. The number that mattered to the founder was not the timeline, it was that we shipped twenty seven changes overnight. Not because we are faster typists. Because the structure underneath finally let changes be cheap.

I want to be careful here. Rebuilding is not the answer most of the time and I am not recommending it. That one was genuinely unrecoverable. Most are not.

What a stall actually looks like from the inside

I said the failure is deferred decisions, which is true, and slightly too tidy. Let me be more honest.

Some of it is that nobody wrote down what done meant, so done keeps moving. Some of it is that the person building it does not want to say the thing is finished because finished invites judgment. Some of it is that the client keeps adding, and every addition is small, and the developer says yes because saying yes is easier than the conversation.

And some of it is just week eight. I am heavily ADHD and I will tell you plainly that starting things was never my problem. Week eight is. Whatever process you use has to survive the point where the project stops being interesting, because it will stop being interesting, and interest is not a plan.

The fix is boring and it happens before the build

There are only three things and none of them are technical.

Decide what done means, in writing, before anyone builds. Not a feature list. A definition a non-technical person could check. If you cannot tell whether it is met by looking, it is not a definition, it is a hope.

Cut to the version that ships. Give a technical person the choice between a ninety nine percent solution that takes two years and a ninety five percent solution that ships in two days, and they will take the ninety nine every time. Scores, not business. Someone has to ask whether that last four percent is worth two years. It usually is not, and people wildly underestimate the ninety five.

Put gates in with money attached. Six stages, one sixth of the price released as each one completes, and the right to walk at any gate keeping everything produced. A gate that costs nothing to miss is a milestone, and milestones slide.

The thing worth checking first

Before you decide whether to rescue or restart, there is one question that tells you most of what you need.

Is the data model sane?

Screens are cheap. Rearranging what appears where is a day. The expensive thing to unpick is the shape of the data underneath, because everything else was built on assumptions about it, and changing it late is where the timeline goes.

If the data model is reasonable, a stalled product is often a two or three day save. If it is not, you are looking at a rebuild, and the honest thing is to say so early rather than bill you to discover it slowly.

I do not have a way for you to check that yourself without a technical person, which is annoying, and I am not going to pretend otherwise. What you can do is ask whoever looks at it to answer that specific question first, before they quote anything, and to show you why.

Anyone good will enjoy the question. It is the interesting part.

Common questions

Should I fire the developer who left it at eighty percent

Usually not, and usually you already have. The failure is normally that nobody wrote down what finished meant, which is not the developer's job to invent halfway through. Replacing them without fixing that reproduces the same stall with a new person.

Is a half-built product in Lovable or Bolt wasted work

Often not. Sometimes the fix is a two or three day save rather than a rebuild. What matters is whether the data model is sane, because that is the expensive thing to unpick, and the shape of the screens rarely is.

How long should a first version take

Ours run six weeks, gated in six stages. That is not a boast about speed, it is a constraint. Six weeks forces the scope conversation to happen at the start, which is exactly the conversation that stalling products never had.