"Never rewrite" is good advice most of the time. Rewrites run late, lose features, and stall the roadmap. But there is a point where a platform costs more to keep than to replace, and founders usually recognise it a year too late. These are the five signals we look for in a technical audit.
1. Feature velocity is falling every quarter
Plot how long a typical feature takes to ship, quarter over quarter. If the line only goes up — and headcount has not gone down — the codebase is fighting you. Engineers are spending their time on the parts that already exist, not the parts you need.
2. Only one person can deploy
If a release depends on a specific human being awake, you do not have a platform; you have a hostage situation. Deployment should be a button, documented, and boring.
3. Dependencies are years out of date
An unsupported framework version is a security incident waiting for a date. When upgrading is "too risky", the honest translation is that nobody understands the code well enough to change it safely. That is the rebuild signal, not a reason to wait.
4. The data model no longer matches the business
You sell subscriptions, but the database only knows one-off orders. You have teams, but every user is an island. When every new feature needs a workaround in the schema, the schema is the product's ceiling.
5. Maintenance costs more than a rebuild would
Add up engineering hours spent on bugs, infrastructure spend on an architecture you would never choose today, and revenue lost to features you cannot ship. Compare that to a scoped rebuild with AI-assisted delivery — often a matter of weeks now, not years. The maths is frequently not close.
- Rebuild in slices behind the existing product; never a big-bang cutover.
- Ship the highest-pain module first so the team feels the win early.
- Freeze nothing — the old system keeps running until the new one has proven itself on real traffic.
The expensive rewrite is the one you start eighteen months after you should have.
