You have a half-built MVP. The developer left, ran out of time, or the project lost steam. It sits on a branch somewhere, almost working, but nobody carried it over the line. Good news: an MVP that’s 70% done almost always gets finished. Here’s how.
1. Resist the urge to rebuild everything
That’s the first instinct, and usually the wrong one. Picking up code you didn’t write is uncomfortable, so the temptation to start fresh is strong. But a nearly-finished MVP holds weeks of work you’ve already paid for. Keep what holds, redo only what’s necessary.
2. Redefine the real finish line
A stalled MVP usually means the scope crept. Before writing any code, decide: what’s the smallest version that can ship and be used by real users? Everything else waits. This is the single decision that unblocks the most projects.
3. Take stock of what exists
A quick audit answers three questions:
- what actually works (not just “on my machine”)?
- what’s started but not finished?
- what’s missing to reach the finish line from step 2?
You come out with a clear list, not a vague impression.
4. Prioritise what blocks the launch
Anything that prevents deploying goes first: shaky authentication, an undeployed database, half-wired payments, blocking bugs. The “nice to have” improvements come after launch, never before.
5. Stabilise before adding
Adding features on an unstable base is building on sand. Fix what breaks, put minimal tests on the critical paths, then move forward. It’s faster in the end, even if it feels counterintuitive.
6. Ship, then iterate
An MVP only has value in users’ hands. Deploy the minimal version defined above, watch what happens, and improve from reality. Launch isn’t the end, it’s where the real decisions start.
That’s exactly how I take over a stalled MVP on a project rescue: I audit, cut the excess, stabilise, and ship it. Fixed price, and you keep the code.
In short
A stalled MVP is almost never worth scrapping. Redefine the finish line, keep what holds, stabilise, and ship a minimal version rather than waiting for “perfect.” Most of the time, there’s less left to do than it looks.
MVP stuck halfway? Get an audit. I’ll tell you what’s salvageable and how much is genuinely left.
Frequently asked questions
How long to finish a taken-over MVP? Often a few weeks once the scope is tightened. The deciding factor isn’t the code left, it’s clarity on the finish line.
What if the code quality is poor? Keep what lets you ship fast, isolate what’s risky, and replace it over time. Rewriting everything before launching is rarely the right call for an MVP.
Should we add tests? The minimum on critical paths, yes. Not full coverage: the goal is to ship and learn, not to reach technical perfection.