Refactor or rewrite from scratch? How to decide
For CTOs and engineersCTO decisions · Updated
Filip Papranecfounder of Digitaliko
Refactoring is changing code to improve its structure without changing what the software does. Refactoring or rewriting from scratch is a decision about how many months of roadmap you are willing to stop. Refactoring in small steps usually wins, because the product keeps earning while you do it.
A rewrite from scratch makes sense in three cases: the code does the wrong thing, you do not own it, or it runs on technology without support. Below is a decision table and a way to refactor without stopping the roadmap.
AI writes all of our code today, and a senior is accountable for the result. Before this, Filip spent years building a SaaS used daily by 60,000+ people. It was never rewritten from scratch. It changed through small, reviewed changes, right in the live product.
Why is a big rewrite almost always more expensive than it looks?
A rewrite looks clean because the new code has no history yet. But you need that history. Behind every odd condition in old code there is usually someone's complaint.
The most common reasons a rewrite gets expensive:
Rewrite from scratch
- You lose the fixes. Old code holds years of small fixes, and customers find the bugs again.
- You pay for two systems. Until the rewrite is done, the old one still needs maintenance and features.
- The roadmap stops. Sales waits for features, and the new system starts out doing less.
- The target moves. By the time the rewrite catches up, the old system has new features.
None of these costs
Refactor in small steps
- The product keeps running and earning.
- Customers notice nothing.
- Every change can be rolled back.
- New features ship alongside the refactoring.
When to refactor and when to rewrite: a decision table
| Situation | What we recommend | Why |
|---|---|---|
| The code does the right thing but is hard to change | Refactor | You want to keep the behaviour and only change the shape of the code. |
| There are no tests | Tests first, then refactor | Without tests you do not know what you broke. |
| One part slows everything else down | Replace that part, refactor the rest | One module behind a stable interface is manageable. |
| The code does the wrong thing, the business has changed | Rewrite that part | There is no point keeping behaviour you do not want. |
| You do not own the code or cannot access it | New system and a data move | There is nothing to refactor. |
| The technology has no support or security patches | Gradual migration | Move it part by part, not all at once. |
| Nobody on the team understands the code | Understand first, decide later | Code nobody understands is not a reason to rewrite. It is a reason to write tests. |
Watch the last row. "Nobody understands it" is the most common argument for a rewrite. It is also the worst. A new team that does not understand the old code will rewrite it without the fixes it contains.
A rewrite is also the easiest upsell. In an audit of one founder's product, the obvious pitch was a monorepo and a backend rewrite in TypeScript. We wrote the opposite: the repositories are fine, add TypeScript module by module, and start with login and permissions.
How do you refactor without stopping the roadmap?
01
Tests for the current behaviour
First describe what the system does today, bugs included. Only then change it.
02
Small steps in the normal flow
No branch that stays unmerged for a month. Every change goes through review and CI.
03
Refactor where you build a feature
Code nobody touches for a month can wait.
04
Build the new part next to the old one
Switch over gradually until you can turn the old one off.
05
CI that really stops a bad change
A green check without tests proves nothing.
AI does the slow, boring part here. Tests for existing behaviour, moving code, renaming. A senior decides what changes and in what order. We describe the rules we give AI for this in Rules for AI code in a team.
When you have tests, refactoring is easy.
Without tests and review, AI only grows your technical debt faster. That is why we say an agent is a model plus a harness. The harness is what stops a bad change.
When is a rewrite from scratch the right call?
When you do not own the code. If the original system is not yours, there is nothing to refactor: a new one is built and the data moves over.
A rewrite follows the same order. First the data and an understanding of what the system really does. Then screen by screen, not everything on one day.
Go through six points before you decide. Tick what is true for your system:
The fourth point weighs most. If the code does the right thing, just badly, refactor.
When we don't recommend it
- You have a senior who knows the system and has time for it. Refactor yourselves. The table above is enough.
- The system is being switched off in a few months. Do not invest in code that is ending. Invest in moving the data.
Want to decide with someone who does this daily?
A senior plugs into your repository and pull requests from day one. Tests first, then changes in small steps, and the roadmap keeps moving. This is how we work as an external developer for product teams.
Tell us which part of the code is slowing you down. We get back to you within two business days, and together we pick what to fix first.
If you'd rather talk first, book a 15-minute meeting with Filip.
Which part of your code would you most like to throw away, and why?
In short
- Refactor when the code does the right thing badly. Rewrite when it does the wrong thing or you do not own it.
- A big rewrite costs the roadmap, the fixes and two systems at once.
- Tests for today's behaviour first, then small steps in the normal flow.
- Even a rewrite goes part by part, never all at once.
Frequently asked questions
When should you refactor and when should you rewrite from scratch?
Refactor when the code does the right thing but is hard to change. Rewrite when it does the wrong thing, you do not own the code, or the technology has lost support. Even then, rewrite in parts, not all at once.
Can you refactor without tests?
You can, but it is a gamble. First write tests for the current behaviour, bugs included. Only then change the code. Without tests, you learn about a bug from a customer.
How long does refactoring take?
It has no fixed end, and that is fine. It happens continuously in regular pull requests, where you are working anyway. A standalone refactoring project lasting months usually never finishes.
Does AI help with refactoring?
Yes, with writing tests, moving code and renaming. Deciding what to change and in what order stays with a senior. Without tests and review, AI only makes the bugs arrive faster.
Ask AI about this article
The AI also draws on our other articles and experience from real projects.
ChatGPTClaudePerplexity
