When to Rewrite vs Refactor Your MVP

Almost nobody needs the rewrite they are asking for. When a founder says the MVP has to be rebuilt, the underlying problem is usually three slow modules, a missing index, and a codebase nobody has documented — all of which are refactor work measured in weeks. A genuine rewrite is justified by four things only: a platform with no upgrade path, a data model that contradicts how the business now works, a cost or performance ceiling the current architecture cannot clear, and a stack you can no longer hire for. Everything else is a refactor wearing a rewrite's clothes. This guide covers the four real signals, the four impostors, what a rewrite costs in weeks and in features that do not ship, how to replace a system while it stays live, and a checklist you can run this afternoon.

Key takeaways: Rewrites fail for the same reason the first system did — the scope was never settled, and this time you are rebuilding a moving target under a feature freeze. Expect a rewrite to cost 1.5–3× the original build and 4–9 months for an MVP-scale product, with 10–20 features not shipped while it runs. Refactor incrementally by default; if you must replace, do it module by module behind a routing layer so the product stays live and value ships every fortnight. Never change the stack and the architecture and the data model in the same project. Ranges below are INFOCRUD planning figures reviewed in September 2026.

Rewrite, refactor, rearchitect — three different purchases

The words get used interchangeably in discovery calls, which is how a two-week job gets quoted as a two-quarter one.

The important line in that table is the third column. A refactor is something you do *while* the business continues. A rewrite is something the business waits for — and the waiting, not the engineering, is what usually kills it.

Four signals that genuinely justify a rewrite

Each of these shares a property: the cost of staying is compounding, and no amount of tidying the existing code removes it.

1. Phase 01The platform underneath has no upgrade path. The runtime is end of life, the framework's major version requires a rewrite anyway, or a vendor you built on is being shut down with a date attached. This is the cleanest case, because the deadline is external and the decision is only about timing
2. Phase 02The data model contradicts the business. You built one user per account and now sell to teams. You built single-tenant and now need one deployment serving many customers. Every feature is now paying a tax at the schema level, and the tax rises with each one. Note that this is still often a migration rather than a rewrite — but it is the one case where a rewrite can be the cheaper migration
3. Phase 03A cost or performance ceiling the architecture cannot clear. Infrastructure spend rises faster than users, or the p95 response time cannot be brought under target without changing the system's shape. This qualifies only when you have the measurements. Without numbers it belongs in the next section
4. Phase 04The stack is one you can no longer hire for. A niche language, an abandoned framework, or a no-code platform you have outgrown, combined with no tests and no documentation. If hiring a developer for this codebase means a six-month search or a rewrite by whoever you find, you are already paying for the rewrite in delay

Two of these four, present together, make the decision for you. One on its own is worth a fortnight of investigation before committing a quarter.

Four that only look like they do

• "The code is messy." Usually true, and rarely the reason your roadmap is slow. Messy code that ships weekly is a working asset. Ask for the three files that cause the most incidents — if the answer is "all of it", nobody has diagnosed anything yet
• "It's slow." Slowness in an MVP is, more often than not, two unindexed queries, an N+1 in a list view, and an image pipeline nobody configured. That is a week of work, not a quarter. Measure before you believe anyone, including yourself
• "The new developer says it's unmaintainable." Every engineer's first instinct in an unfamiliar codebase is to rewrite it — it is faster to write code than to read it. Take the assessment seriously, take the recommendation slowly, and ask for the diagnosis rather than the prescription
• "It won't scale." Ask what traffic it must survive and what it does today. Most MVPs are being redesigned for a load they are two funding rounds away from. Scaling work done before the users arrive is a bet on a shape of growth you cannot know yet

There is a fifth, quieter one: the original developer left. That is a documentation and handover problem, and rewriting the system to escape it destroys the only remaining record of how the business actually works — because the rules live in that code, undocumented, and the rewrite reimplements them from memory.

What a rewrite actually costs

Founders price a rewrite against the original build quote, which is the wrong comparison. The original built an unknown product with a small scope. The rewrite has to reproduce everything the product learned since, including the parts nobody wrote down.

The line that does not appear on any quote is the third-from-last one. A six-month rewrite with a feature freeze is fifteen-odd features your customers asked for and did not get, a sales team with nothing new to say for two quarters, and a support backlog that ages in place. For a company still looking for product-market fit, that is usually the real cost — not the invoice.

And the failure mode is specific. Rewrites run long because the requirement was "do what the old one does", which nobody has written down. Month four is where it is normally discovered: the old system is still live, the new one is at 80%, and the team is now maintaining two codebases with one budget. If you take one thing from this article, make it this — never start a rewrite without a written inventory of what the current system does, including the behaviours that were accidents.

The strangler pattern: replacing a system while it stays live

If a replacement really is warranted, the way to do it is incrementally, module by module, with the old system serving traffic the entire time. The name comes from the strangler fig, which grows around its host until the host is gone; in practice it is four steps.

1. Phase 01Put a routing layer in front. A reverse proxy, an API gateway, or simply a route table in the existing application. Everything still goes to the old system. Nothing has changed for users, and this is the step that makes every later step reversible
2. Phase 02Pick the module with the most pain and the fewest dependencies. Not the biggest, not the most interesting — the one that hurts weekly and touches least. Billing and reporting are common first candidates; authentication almost never is
3. Phase 03Build that one module new, and switch its routes. Behind a flag, for internal users first, then a percentage of traffic. If it misbehaves, you move the route back. Both systems read the same database during the transition, or the new one owns its tables and syncs back — decide which before you start, because doing both is where data drifts
4. Phase 04Delete the old module, then repeat. Deleting is the step teams skip, and skipping it leaves you permanently running two systems. A module is not migrated until its old code is gone

This is slower in engineering-hours than a clean-sheet rewrite, and faster in calendar time to each unit of value. You ship something every two to three weeks, you can stop after any module if priorities change, and you are never in the position of having spent four months with nothing in production. The trade-off is real — for a period you maintain two implementations and the routing layer that arbitrates them — which is why it is worth being sure the replacement is necessary at all.

A decision checklist you can run in an afternoon

Answer these before anyone writes a line of new code. The pattern in the answers is the decision.

Two rules on top of the table. First, never change the stack, the architecture, and the data model in one project — change one, ship, then reassess; teams that change all three are not doing a rewrite, they are starting a new company with an old customer list. Second, whatever the answers, timebox a two-week diagnostic first: profile the slow paths, add tests to the money path, and fix the top three issues. A surprising share of rewrite conversations end there, and the ones that do not now have evidence instead of a feeling.

Two snapshots

*Composite examples drawn from patterns we see in architecture reviews; figures are representative rather than a specific engagement.*

The refactor. A B2B scheduling product, eighteen months live, forty paying customers. The founder asked for a rebuild after the dashboard began taking eleven seconds to load and a new developer called the codebase unmaintainable. The diagnosis took four days: two missing indexes, an N+1 query in the customer list, and a report that recalculated from the full history on every page view. Three weeks of work — indexes, a cached summary table, tests around billing — brought the dashboard under a second. The code is still messy. It is also still shipping features, which the rewrite would have stopped for six months.

The rewrite. A logistics MVP built on a no-code platform that had served it well for a year. The trigger was not messiness: the platform capped concurrent jobs, priced per record in a way that grew faster than revenue, and provided no path to the customer-specific pricing rules the business now sold on. Three of the four real signals, present together. It was replaced module by module over five months behind a routing layer — read-only reporting first, then job creation, then pricing — with the old platform live throughout and the last module retired only once its replacement had run a full billing cycle. Slower than a clean rewrite. Nobody lost a week of operations.

The difference between those two is not code quality. It is whether the cost of staying was compounding, and whether anyone had measured it.

Frequently asked questions

How long does an MVP rewrite really take?

Four to nine months for a product that originally took eight to fourteen weeks, and overruns are normal rather than exceptional. The multiplier is not incompetence — it is that the rewrite must reproduce every behaviour the product acquired after launch, including undocumented ones that customers now depend on. Assume the estimate you are given covers the specification someone wrote down, and that the gap between that and the live system is where the overrun lives.

Can we rewrite and keep shipping features at the same time?

Not with one team. With a strangler approach you can keep shipping in the modules that have not been touched yet, which is the practical version of having both. Splitting a small team into "new system" and "keep the old one alive" halves both and is the most common way a rewrite quietly fails at month four.

Our developer insists the code is unmaintainable. Are they wrong?

Probably not wrong about the code, and probably wrong about the remedy. Ask for a diagnosis rather than a recommendation: which modules, what specifically makes a change expensive there, and what would a two-week improvement deliver. An engineer who can answer that is worth listening to about the rewrite as well. One who cannot is reacting to unfamiliarity, which every engineer does in a codebase they did not write.

Should we switch the stack while we are rewriting anyway?

Only if the stack is one of the reasons for the rewrite — end of life, or unhireable. Otherwise you are adding an unknown to a project whose main risk is already unknowns, and losing the one advantage a rewrite has, which is a team that already knows the tools. The strongest predictor of a rewrite finishing is how few things changed at once.

What does a refactor cost?

A focused one is typically ₹1.5–6 lakh, two to six weeks, and it should be scoped against named outcomes — a page under a second, the billing path covered by tests, the deployment reproducible. If a quote for improving an existing system is approaching the cost of building it again, that is itself a signal worth taking to the checklist above. Our MVP cost bands give the comparison point.

Is a frontend-only rewrite different?

Yes, and it is the safest kind. A user interface can be replaced screen by screen behind the same APIs, each screen shipped independently, with no data migration and easy rollback. If the complaint is that the product looks dated or the interface is hard to change, you almost certainly do not need to touch the server at all.

How do we avoid needing this again in two years?

Mostly by scoping the first version honestly — the decisions a founder owns before the build starts determine how much of this you inherit. After launch: keep tests on the money path, keep dependencies current on a schedule rather than in a crisis, document decisions as they are made, and budget 15–20% of build cost a year for maintenance. Systems do not become unmaintainable suddenly. They do it one deferred fortnight at a time.

The bottom line

The question is almost never "rewrite or refactor". It is "is the cost of staying compounding, and have we measured it?" If the answer is no, refactor — name three modules, add tests to the money path, fix the slow queries, and keep shipping. If the answer is yes on two or more of the four real signals, replace incrementally behind a routing layer, module by module, with the product live throughout and something delivered every fortnight. What almost never works is stopping the roadmap for six months to rebuild a system nobody has written down, on a stack nobody has used, to a specification that is still changing. The rewrites that succeed are the ones that were boring, sequential, and reversible at every step.

If you are in this decision now and want an outside read on it, a two-week diagnostic — measurements, the three modules that actually hurt, and a costed refactor-or-replace recommendation — is usually enough to settle it. Explore our core development work, see how a single workflow taken end to end with tests and runbooks holds up on Offybox, or book a 30-minute architecture review call and we will tell you which of the two you are looking at, and what it should cost.