Every founder I've worked with who inherited a stalled codebase eventually asks the same question, usually with a specific kind of tired voice:
"Should we just rewrite the whole thing?"
They've been living with it long enough to know what's broken. They can see the seams. Every new feature takes twice as long as it should. Bugs keep coming back. The last three engineers who touched it all quit or ghosted. And on the other side of the question is the fantasy: a clean codebase, a fast team, no more surprises.
I've been on both sides of this decision — asked to rewrite systems that shouldn't have been rewritten, and asked to refactor systems that genuinely needed a rewrite. The mistake is the same in both directions: the decision is treated as a technical question when it's actually a business question.
Here's the framework I use, and the middle path most founders miss.
First: are you actually facing this decision?
Before you spend a week debating rewrite vs refactor, make sure you're in the situation the debate is for. Most of the time, founders think they need a rewrite when they actually need one of three simpler things:
One senior person for two weeks. Sometimes the problem isn't the code — it's that nobody currently touching it understands it. Bringing in an experienced pair of eyes to audit, document, and fix the three worst hotspots often changes everything. Not glamorous, but it's the highest-ROI move on this list.
A test suite that doesn't exist. If every deploy feels like Russian roulette, the fix isn't rewriting the app — it's writing the tests that let you change the app safely. A codebase you can't change is a codebase you're afraid of, not a codebase that's actually bad.
A hosting or infrastructure change. "The app is slow" and "the app is broken" often turn out to be "the database is on the smallest tier" or "there's no caching layer." I've seen founders greenlight a $60k rewrite for a problem a $200 database upgrade would have fixed.
You're actually facing the rewrite-vs-refactor question when all three of the above are true:
1. The code is genuinely tangled — not just unfamiliar. Multiple engineers have looked at it and independently said the same thing. 2. Adding a new feature costs 3–5× what an equivalent feature would cost on a clean codebase, and it's not getting better. 3. The business problem you need to solve requires a structural change the current architecture can't accommodate (a new user role, a new data model, multi-tenancy, a different scale profile).
If you only have one of those, you don't need a rewrite. You need one of the three simpler things above.
The refactor path — when it wins (usually)
Refactoring is the default answer, and the right one, roughly 80% of the time. Here's why:
The code you have works, even if it's ugly. Every feature in it represents customer feedback, edge cases you discovered the hard way, and integrations you painstakingly got right. A rewrite loses all of that as tacit knowledge and has to relearn it. Every real rewrite I've watched has re-discovered the same three or four "weird" behaviors that turned out to be load-bearing customer requirements.
Refactoring is reversible. If a refactor goes badly, you can pause, ship the current state, and continue later. A rewrite is a giant bet — you can't ship "half of the rewrite" alongside the old system without doing the strangler pattern (more on that below), and most teams don't.
Refactoring keeps revenue flowing. During a full rewrite, you typically freeze the old codebase — no new features, no bug fixes beyond critical, everything sacrificed to the rewrite. That freeze is usually where founders lose customers and momentum.
Refactoring compounds. Each round of refactoring makes the next feature slightly cheaper. Rewrites don't compound; they reset.
The refactor path wins when your business is still learning what to build, when your customer base is growing, when you can afford to move steadily but not to stop, and when the architecture is fundamentally sound but the implementation is messy.
The rewrite path — when it actually wins (rarely)
Genuine rewrites are rare and specific. In seven years of shipping products across industries, I can count on one hand the situations where I'd tell a founder to rewrite.
A rewrite is the right call when:
The core assumption underneath the app is wrong. You built a single-tenant SaaS and now every enterprise deal requires you to be multi-tenant. You built for one country and now compliance forces you to isolate data by region. You built synchronous and now the business requires eventual consistency. These aren't refactors; they're different products.
The technology stack is genuinely unsupportable. Not "old" — unsupportable. Frameworks abandoned by their maintainers, database engines that no one can hire for, hosting platforms that shut down. There's a difference between "I don't like Laravel" and "PHP 5.6 is EOL and my cloud provider is deprecating it in 6 months."
The whole team walked away and no one wants to touch it. This is a business signal, not a technical one. If your ability to hire is materially blocked by the current stack, that's a real cost.
The rewrite pays for itself in under 12 months. Not "it'll be nice" — actual math. If a rewrite unlocks a specific deal, a specific price increase, or a specific cost reduction that repays the investment in a year or less, do it. If you can't put a number on the payback, you're not making a business decision.
Everything else is either a refactor or the third path most founders miss.
The third path: surgical rewrite (the "strangler" pattern)
The mistake most rewrite advocates make is treating the decision as binary. It isn't. There's a third option that gets the benefits of both and the downsides of neither, and it's the one I recommend most often.
Keep the old system running. Route new features through a new system. Migrate the old features over one at a time, only when you touch them.
This is the strangler pattern (named after strangler figs, which grow around a host tree and gradually replace it). In practice:
- You add a routing layer in front of the old app.
- New features get built in the new stack, behind the routing layer.
- Old features stay on the old stack until they're specifically due for change.
- Over 6–18 months, the new stack grows and the old one shrinks. Eventually you can turn the old one off.
The advantage: you never stop shipping features to customers. The old app keeps working. Revenue keeps flowing. You migrate opportunistically — when a feature needs a change anyway, you rebuild it in the new stack instead of patching the old one.
The disadvantage: you're running two systems for a while. You'll have some duplication, some routing complexity, and you'll need discipline about not letting the "temporary" state become permanent (it will if you don't set milestones).
Almost every large-company rewrite you've heard of that worked used a variant of this pattern. Almost every "big bang" rewrite you've heard of that failed did not.
The 5-question decision framework
When a founder brings me this question, I walk through these five questions. Not one of them is technical.
1. Is your revenue growing, flat, or declining? If revenue is growing, you cannot afford a freeze. Do the strangler pattern or refactor. If it's declining, the honest question is whether the code is the reason — if not, a rewrite won't save you; product-market fit will.
2. How much runway do you have? Rewrites take longer than you estimate. Every single one I've watched or done overran the timeline by 30–60%. If you have less than 12 months of runway, you cannot afford a rewrite that takes 6 months of engineering with no shippable value in between.
3. What specific business outcome does the rewrite unlock? "Faster development going forward" is not an outcome — it's a hope. "We can close enterprise deals that require multi-tenancy" is an outcome. "We can offer real-time collaboration that our competitor charges 3× for" is an outcome. If you can't name the outcome in one sentence, you don't have a business case.
4. Who is going to do this work? The same team that built the current codebase? They'll rebuild the same class of problems in the new one — that's not a slight; it's how humans work. A new team with the same processes? Same result. A rewrite is only likely to end better than a refactor if the people, the process, or both are also different.
5. What happens if you don't do this for 6 more months? If the honest answer is "we ship a bit slower and grumble more," refactor. If it's "we lose our third-largest customer" or "we can't take on the deal in front of us," now you have a real forcing function.
If four out of five of these questions point the same direction, that's your answer. If they're mixed, the answer is almost always the surgical/strangler path.
A real example
I worked with a small business owner who ran an e-commerce site that had been built by a contractor 3 years earlier and abandoned. The site worked but every change took weeks. They wanted to rewrite the whole thing on a modern stack.
We ran the framework:
- Revenue: growing (couldn't afford a freeze)
- Runway: healthy but not infinite
- Business outcome: "we want to add a customer loyalty program the current site can't support"
- Team: same solo developer who inherited the site (no rewrite would fix the process)
- 6-month cost of doing nothing: annoying, not existential
The answer wasn't rewrite. It was a two-week refactor of the checkout flow (the one hotspot that mattered), plus a new loyalty module built as a separate service that talked to the existing site via API. Six weeks of work instead of six months. The old codebase kept doing its job. The new feature shipped. Revenue kept growing while it was happening.
That's what "surgical" looks like in practice: you build the new thing next to the old thing, not on top of the ashes of it.
What to do this week
If you're the founder reading this and this decision has been hanging over you:
Do not make the decision under pressure. The worst rewrites I've seen were started in a panic — after a bad outage, after a senior developer quit, after a big customer complaint. Give yourself a week before committing to anything structural.
Get an outside opinion. Not from a firm that will sell you a rewrite (they'll always recommend one). From someone whose incentive is to give you the honest answer — a technical friend, an advisor, or an independent code audit. Two hours with the right person will save you months of the wrong decision.
Run the 5 questions above with your team. Write down the answers. If you can't put concrete numbers or specific outcomes next to each one, you're not ready to decide.
If you're still not sure what your project actually needs, the free MVP planner tool on this site will lay out a realistic scope, timeline, and cost estimate in about 60 seconds. It won't tell you whether to rewrite — but it'll give you a baseline for what a well-scoped version of your product actually looks like, which is often the missing piece in this decision.
Refactor is the default. Rewrite is rare and specific. The strangler pattern is what you probably actually want.
The founders who make this call well aren't the ones with the best technical instincts. They're the ones who ask the business question first and let the technical answer follow.
---
If you're staring at a codebase and don't know which of the three paths yours is on, that's exactly the kind of thing I do for a living. Reach out via the contact page with a paragraph about what's going on and I'll tell you honestly what I'd do in your position — no sales pitch.