Rebuild vs Refactor: Fixing a Broken MVP

A founder emails us roughly once a fortnight with the same message: "The codebase is a mess, the original developer is gone, everything takes three times longer than it should — should we just start again?" The instinct is understandable. The answer is usually no, and the reason has almost nothing to do with code quality.

Should you rebuild or refactor your MVP?

Refactor incrementally by default — a rebuild is almost always more expensive, slower, and riskier than founders estimate, because you throw away every bug fix and domain decision embedded in the existing code and have to re-earn all of them. Rebuild only when a specific, nameable blocker makes incremental improvement impossible.

That ugly codebase is ugly for a reason. Every strange conditional is a real customer situation someone hit at 11pm. Every awkward field on the orders table is a case the original spec missed. None of it is written down anywhere, so when you rebuild you don't restart from the spec — you restart from a worse spec than the messy code already encodes, and rediscover each edge case one angry support ticket at a time.

Rebuild vs refactor: the honest comparison

| | Incremental refactor | Full rebuild | |---|---|---| | Cost | Absorbed into normal sprints | £15K–£40K as a distinct project | | Risk | Low — small, reversible changes | High — long no-value period, regressions | | Time to value | Immediate; ships continuously | 3–6 months before parity | | What you keep | Users, data, integrations, edge-case fixes | The idea, the design, the lessons | | What you lose | Architectural purity; some debt stays | Embedded domain knowledge, tested fixes | | Best for | Working products with accumulated debt | Dead-end stacks, throwaway prototypes |

The row that decides most cases is "time to value." A refactor improves things in week one and keeps improving them. A rebuild delivers nothing until it reaches parity with what you already have — and parity is not a win, it's a return to the starting line, months and tens of thousands of pounds later.

What does a rebuild actually cost?

The number founders quote us is usually the build cost. The real cost has four parts, and three of them are invisible on a quote.

The build itself. A rebuild is not cheaper than the original MVP, and often dearer — the scope is now everything the product currently does, not the minimum you needed to validate. Most rebuilds we scope land between £15K and £40K, in line with our guide to UK MVP costs and our pricing.

The frozen feature pipeline. While the rebuild runs, competitors ship and customers wait. Three months of zero new features carries a revenue cost that never appears on the invoice.

The migration. Moving live customer data from the old schema to the new one is a project in itself — usually a few weeks, always underestimated. Accounts, subscriptions, historical records, and third-party integrations all have to survive the crossing intact.

The second-system tax. Teams that rebuild rarely rebuild the same thing. They fix the architecture and add the features they always wanted, and the six-week estimate becomes five months.

The cheap first move is not choosing. It's a short paid code audit — a few days of senior engineering time reading the codebase, running the test suite (or noting its absence), reviewing the data model and security, and producing a written verdict with costed options. Set against a £25K commitment made on a hunch, an audit is a rounding error, and it frequently finds that three modules cause ninety percent of the pain. Fix those and the "we need a rebuild" feeling disappears.

When is a rebuild genuinely justified?

There are real triggers. If you can point at one of these, stop refactoring and rebuild deliberately.

The stack can't support the next twelve months. Not "we don't like PHP" — a concrete ceiling. The framework is end-of-life with no security patches. The database can't do what the product now needs. The hosting model can't meet a data-residency requirement you've just signed up to. If your roadmap requires something the foundation structurally cannot do, patching is deferral, not a plan. Our 2026 SaaS tech stack guide is a decent sanity check on whether your foundation has years left in it.

No test coverage and nobody who understands it. Either alone is survivable. Together they're fatal: you cannot safely change code you don't understand and cannot verify. Every edit becomes a coin flip. If the original developer is unreachable and the suite is empty, making the code knowable can genuinely cost more than rebuilding it with tests from day one.

Security or compliance holes that reach the foundations. Credentials in the client bundle, no authorisation checks on endpoints, customer data with no tenant isolation, no audit trail. If you're chasing enterprise deals or handling health or financial data, retrofitting isolation into a system that never had it is often harder than building it in correctly.

It was a throwaway prototype that was never meant for production. This is the most common legitimate trigger in 2026. An AI-generated app from Lovable, Bolt, or v0, or a no-code build straining past what the platform supports, did its job: it proved demand and became your spec. But it was built to be shown, not run. We cover exactly where those break — auth edge cases, data modelling, payments, security — in our piece on AI-built MVPs. Rebuilding a prototype isn't really a rebuild. It's the first real build, and the prototype has already paid for itself by de-risking it.

Note what is not on that list: ugly code, an unfashionable framework, or an engineer who'd simply rather start clean. Those are preferences, and none is worth £25K and a frozen roadmap.

How do you refactor without stopping feature work?

The fear is that refactoring means a quarter of invisible work. It doesn't, if you work in the right shape.

Use the strangler fig pattern. Instead of replacing the system, grow the new one around it. Route one endpoint or one page through new code while everything else runs untouched. Prove it in production. Take the next one. Repeat until the old system is doing nothing and can be deleted quietly. Every step ships and every step is reversible.

Refactor along the path of the work. Don't schedule "refactoring sprints" — they're the first thing cut when a deadline appears. When a feature touches a bad module, clean that module as part of the feature. Debt gets paid down exactly where it hurts, inside work you were doing anyway.

Write tests before you change anything. Characterisation tests that pin down what the code currently does — bugs included — turn a frightening edit into a safe one. It's also the cheapest way to recover knowledge from code nobody understands: writing the test forces you to learn the behaviour.

Fix the data model first. Ugly UI code can live for years; a bad schema taxes every feature you will ever build on top of it.

Set a stop rule. Agree up front what "good enough" means — deploys under ten minutes, the top three recurring bugs gone, new features taking days rather than weeks. Refactoring without a finish line becomes its own runaway project.

Frequently asked questions

Can you take over someone else's codebase?

Yes — we do it regularly, and we audit before committing to anything. A few days of senior review gives you a written assessment of the data model, security, test coverage, and deployment setup, plus costed options for both paths — even if the answer is that your current developer should keep the work. Our software development team takes over delivery only if the numbers say so.

How long does a rebuild take?

Expect three to six months to reach parity with a product that took eight weeks to build the first time. The original MVP had minimum scope; a rebuild inherits everything the product does today, plus data migration and a cutover. If someone quotes six weeks to rebuild a live product, they haven't met the edge cases yet.

Should I rebuild an AI-generated prototype?

Usually yes — but treat it as your first production build, not a failure. A prototype from Lovable or Bolt proved demand and answered the product questions, which is exactly what it was for. Keep the UI decisions, the flows, and the copy; rebuild the data model, auth, payments, and security properly underneath.

Will a rebuild make the product faster to work on?

Only if you know why the current one is slow. If the cause is an unfixable architecture, yes. If it's missing tests, no CI, and a manual deploy, a rebuild reproduces the same conditions in a new language within a year. Fix the process before you blame the code.

The bottom line

Refactor by default. Rebuild only when you can name the blocker — a stack with no future, unknowable untested code, foundational security gaps, or a prototype never meant to reach production. Everything else is a preference dressed up as an emergency, and it costs £15K–£40K and a frozen roadmap to indulge.

Bring us the codebase and we'll run a short paid audit before anyone commits to anything. Book a scoping call — you'll get an honest verdict on which path is actually cheaper, in writing, even if that verdict is "keep what you have."