Almost every founder facing a broken MVP asks whether to rewrite it. Almost every time, the answer is no — and the reason is arithmetic, not sentiment.
A broken MVP usually presents in one of three ways: it falls over under real usage, every change breaks something else, or the original developers left and nobody understands it. The instinct is to start again. That instinct is expensive and usually wrong.
Why the rewrite is a trap
The rewrite looks attractive because the new system is imaginary, and imaginary systems have no bugs. In reality:
- The existing code encodes years of edge cases nobody documented — they will be rediscovered as production incidents
- You freeze feature development for months while competitors do not
- The rewrite hits the same complexity, because the complexity is in the domain, not the code
- Estimates for rewrites are wrong by a wide margin, consistently, in every organisation
Step 1: Stop the bleeding
Before improving anything, make the system observable and recoverable. You cannot fix what you cannot see, and you cannot experiment without a way back.
- Error tracking, so failures are known rather than reported by customers
- Uptime and key-transaction monitoring — checkout, signup, payment
- A rollback that works and has been tested
- Backups, and a restore that has actually been performed once
Step 2: Triage, do not inventory
Resist the urge to list everything wrong. Sort problems by consequence:
| Bucket | Definition | Action |
|---|---|---|
| Bleeding | Loses money, data, or customers right now | Fix this week |
| Blocking | Prevents shipping the next quarter's roadmap | Fix this quarter |
| Compounding | Makes every change slower | Schedule deliberately |
| Cosmetic | Offends taste, costs nothing | Never |
Most rescue engagements find two or three items in the first bucket and a handful in the second. That is a manageable programme of work — quite different from the overwhelming impression the team had before things were sorted.
Step 3: Fix in the order that compounds
- Data integrity first — corrupted or lost data is unrecoverable in a way that downtime is not
- Then the deployment path — until releasing is safe and frequent, every other fix ships slowly and riskily
- Then the top failure source — usually one or two endpoints or queries cause most incidents
- Then the change-blocker — the coupling or missing test coverage that makes the team afraid to touch things
- Only then, performance and polish
Step 4: Prevent the relapse
- Tests on the paths that hurt — money, auth, and the specific things that broke
- A written decision log so the next engineer inherits reasoning, not just code
- A deployment process that anyone on the team can run
- An explicit rule that the roadmap includes maintenance capacity — debt returns otherwise
A rescue is not a cleanup. It is a small number of targeted changes that move the system from unsafe to boring — and boring is what lets a team ship again.
Choose a repair boundary before a rewrite
Demonstrate that one failing journey can be stabilised. Use the result to estimate the next slice and challenge assumptions about replacement.
- Write a regression check around the observed failure.
- Repair a narrow boundary and verify adjacent behaviours.
- Compare repair and replacement including migration and parallel operation.
Frequently asked questions
Should we rewrite our MVP or fix it?
Fix it, unless the platform is unsupportable, the product has fundamentally changed, or the whole system can be rebuilt in a few weeks. Rewrites freeze feature work for months, rediscover forgotten edge cases as production incidents, and consistently overrun their estimates.
How long does an MVP rescue take?
Triage takes days. Stabilising the critical issues typically takes two to six weeks depending on severity. Full remediation of compounding debt is a quarter or more — but it happens alongside feature work rather than instead of it.
Our original developers are gone. Is the code still salvageable?
Almost always. Losing the authors makes the work slower, not impossible: the first task is reconstructing how the system actually behaves — through reading, instrumentation, and characterisation tests — before changing anything.
How do we know if our MVP is actually broken or just imperfect?
Ask whether it loses money or data, whether it prevents shipping the roadmap, and whether the team is afraid to deploy. If none of those are true, you have an imperfect MVP — which is normal and not worth an intervention.
When should we pause feature development during recovery?
When ongoing changes obstruct diagnosis or increase material data and availability risks. Define the pause scope and the evidence needed to resume delivery.
MVP in trouble?
We triage in days and tell you honestly whether it needs a rescue, a rewrite, or nothing at all.
Further reading
MVP Technical Audit: What We Check in the First 48 Hours
Most MVP audits produce a document. A useful one produces decisions: what is on fire, what can wait, and what it costs to fix.
Startup Technical Debt: How Much Is Too Much?
Every startup has technical debt, and most of it was the right call. The question is not how to eliminate it — it is which parts are charging interest you can no longer afford.