Rewrite or Repair
Most teams reach for a rewrite too early. Repair is slower to sell but often faster to deliver, especially when the product still has momentum.
A rewrite resets more than code
Rewrites discard local knowledge. Even if the old system is awkward, it usually contains hidden business rules, small UX choices, and operational constraints that are easy to miss on a clean slate.
That is why rewrites often reintroduce solved problems while delaying roadmap work. The new stack feels cleaner, but the organization absorbs a large execution tax.
Repair works when the seams are visible
If the current system can be segmented, instrumented, and incrementally replaced, repair is usually the better move. The team learns while improving the product, and delivery does not stop.
The key question is not whether the code is ugly. It is whether the boundaries are good enough to change one piece without destabilizing the rest.
- Stabilize the shell first.
- Measure before replacing core flows.
- Move the highest-churn surfaces onto cleaner patterns.