When to rewrite vs refactor: a decision framework for small teams

Every codebase over two years old gets nominated for a rewrite. Almost none of them need one.

The four conditions

I agree to a rewrite only when at least three of these are true:

1. The runtime or framework is genuinely dead. No security patches, no upgrade path, hiring is a problem.
2. The domain model is wrong at the root, not just messy. Refactoring cannot fix a data model that encodes the wrong idea.
3. The product direction has changed so much that most existing code is answering questions nobody asks anymore.
4. There is a written, funded plan for feature freeze during the rewrite, agreed by whoever owns revenue.

If you have two or fewer, refactor.

What people mistake for rewrite conditions

• *"The code is ugly."* Ugly code that works is an asset. Rewrite the ugliest 5%.
• *"We picked the wrong CSS framework."* That is a migration, not a rewrite.
• *"Nobody understands it."* That is a documentation and ownership problem, and a rewrite will reproduce it in eighteen months.
• *"It is slow."* Profile first. Most performance problems live in three queries and one render path.

The cheaper middle path

The strangler fig: stand the new system up beside the old one, route one route or one feature at a time, delete the old code as each slice lands. It is slower on paper and dramatically faster in practice because you never stop shipping.

Concretely:

• Put a routing layer in front of both systems.
• Move the least-coupled, highest-pain surface first.
• Every slice must be shippable on its own, with the old path still working.
• Delete old code as part of each slice, not "later".

The honest cost

A rewrite of a two-year-old product typically takes as long as the original build and delivers no new features. Say that number out loud before the decision, not after. If the business cannot survive six months of feature freeze, the decision is already made for you.