Rebuilding too early wastes engineering capacity. Rebuilding too late constrains the business.
RECOGNISING WHEN DEBT BECOMES A CONSTRAINT
Technical debt is normal in early-stage products. It becomes a critical issue when every new feature requires touching five unrelated systems or when a simple change breaks existing functionality.
If adding a payment option or expanding to a second market takes months instead of days, the codebase has become a constraint on business growth.
THE INCREMENTAL VS COMPLETE REBUILD SPECTRUM
The choice is rarely binary. Between maintaining the status quo and a full rewrite, there is a spectrum of incremental replacement strategies.
| METRIC | INCREMENTAL REBUILD | FULL REWRITE |
|---|---|---|
| Risk | Lower | High |
| Delivery interruption | Minimal | Potentially significant |
| Migration | Progressive | Cutover |
| Feedback | Continuous | Delayed |
| Best when | System boundaries can be isolated | Existing architecture fundamentally prevents evolution |
TECHNICAL DEBT BECOMES A BUSINESS PROBLEM WHEN IT CHANGES WHAT THE BUSINESS CAN DO.
A constrained domain can be replaced progressively while traffic migrates from the existing implementation.
WHAT TO PRESERVE
THE CODE MAY GO. THE KNOWLEDGE CANNOT.
A rewrite that loses operational knowledge is not a clean rebuild.
It is a regression with new code.
SHOULD WE REBUILD?
The best rebuilds look nothing like rewrites.
They look like gradual migrations where the old and new systems coexist until the transition is complete.
THE GOAL IS NOT A PERFECT CODEBASE. IT IS A CAPABLE ONE.
A capable codebase allows the business to move at the speed its market demands.
The rebuild decision should be driven by business capability requirements, not engineering aesthetics.