Your MVP Didn't Fail. It Stalled.

It rarely ends with a fight.

For the first two months the updates arrive every Friday, with screenshots. Then they're fortnightly. Then they're a sentence: "just finishing off a few things". The demo link still works, but it hasn't changed since June. You send a friendly nudge and get a friendly reply, and somehow the two of you have been friendly at each other for six weeks while nothing has moved.

That's what stalling looks like. Not a disaster. A slow leak, and it's easily the most common way an MVP dies in this country, because nobody involved ever has to admit anything is wrong.

Where do builds actually stop?

Almost never at the start, and almost never at the hard technical bit. They stop in the same stretch every time: after the thing works in a demo, before the thing works for strangers.

There's a reason that particular stretch is where momentum dies, and it isn't laziness.

The last stretch has no glory in it. The first eighty per cent is visible. Screens appear, buttons work, everyone's pleased with themselves. The last stretch is error handling, permissions, backups, edge cases, the fourteen ways a payment can go sideways. It's slow, it looks like nothing from the outside, and nobody has ever said "wow" at a well-handled timeout.

Nobody wrote down what done meant. If "finished" was never defined in writing, then finished is whatever the person holding the keyboard decides it is on the day, and the answer will move. This is the same root cause behind most failed projects, which we pulled apart in why web projects blow up.

The scope crept sideways instead of forward. Every time you asked for one more small thing, and every time they said yes without a change note, the finish line moved a fortnight further away. Both parties do this. It feels like good service in the moment.

The money ran out at the worst possible point. A fixed price gets set against the visible eighty per cent, because that's the part everyone can imagine. When the invisible part arrives, there's no budget and no appetite left, so it just tapers off.

The person who understood it left. Freelancer took a full-time job. The agency's senior dev moved to a bigger client. Nobody handed anything over, because there was nothing written down to hand over. What remains is a codebase only one absent person ever understood.

None of those require a villain. Which is exactly why it keeps happening to sensible people who did reasonable due diligence.

Is it salvageable?

Usually more than you'd think, but the answer depends on five things, in this order.

1. Can you actually get it? Before anything else, find out whether you can put your hands on the code, the database, the domain and the hosting without anyone's permission. If you can't, that's the first job and it's a different problem to the one you thought you had. There's a ten-minute audit in locked out of your own website that tells you exactly where you stand.

2. Does it run somewhere other than their laptop? If a new developer can get it running on their own machine in a day, you have a real asset. If nobody can start it without one specific person on the phone, you have an expensive prototype and a hostage situation, in that order.

3. Is there a real structure underneath? Not the screens, the data. Customers, orders, jobs, whatever your business runs on. Sensible structure underneath is the expensive part to get right and the part worth paying for twice over. Pretty screens on top of a mess are far cheaper to redo than the reverse.

4. How much of it is bespoke for no reason? Every project has a handful of genuinely custom things that are the actual point. Around them there should be ordinary, boring, well-trodden components: logins, payments, email, file uploads. When those have all been hand-rolled from scratch, that's usually where the time went and where the risk is buried.

5. Does it match what you now know? Six months of talking to customers has probably changed your view. If half the build serves an idea you've since abandoned, some of it is going in the bin for commercial reasons, not technical ones, and that's fine.

Add those up and you get a fairly clear read. It's rare for the answer to be "burn it all". It's also rare for the answer to be "just finish it", which is what the person who stalled will usually tell you, because that's the cheapest sentence in the world to say.

What should you ask before spending another dollar?

Whether you're going back to the original builder or taking it to someone new, these are the questions that change the outcome.

"What specifically is left, as a list?" Not a percentage. A list, in plain English, with each item small enough to finish in a few days. A percentage is a feeling. A list is a plan, and the act of writing one flushes out whether anyone actually knows.

"What does done mean for each item?" Done means a real person can do the thing on their own phone without you present. Anything else is a status, not a finish.

"What did you decide not to build, and why?" A good answer here tells you more about someone's judgment than anything on their portfolio. Everyone's happy to list what they built.

"Who else can run this if you're hit by a bus?" You're not being morbid, you're asking whether the knowledge exists anywhere except one person's memory. The answer should involve a repository you can access and something written down.

"What would you keep and what would you replace?" Ask this of a new team, and listen for specifics. "We'd keep your data model and the booking flow, we'd replace the auth and the payment handling" is a real assessment. "It's a mess, we'd start again" before they've looked properly is a sales position.

How do you restart without setting fire to the relationship?

Assume untidiness rather than bad faith, at least to start. Most stalled builds are the product of an optimistic quote and a busy calendar, not dishonesty.

Put it in writing, warmly and specifically. You'd like the outstanding items as a list, access to the code and the accounts in your name, and a date by which each will happen. Nine times out of ten, that email alone gets things moving, because vagueness is what let it drift in the first place.

If you're going to move on, get everything transferred while the relationship is still cordial. Access requested after a falling-out is a much slower conversation than access requested during a polite one.

And be honest with yourself about the first eighty per cent. You paid for it, you own it, and a lot of what looks like wasted money is actually a very detailed brief written in code. Knowing what the thing should be is worth real money, and you already have that. The part you're missing is the last stretch, which is the part almost nobody quotes properly the first time.

If you want an outside read on whether yours is worth finishing, we'll look at it and tell you straight. We do this often enough that we'd rather tell you it's fine and lose a rebuild than pretend it isn't.