Repair, rebuild, or retire? A decision framework.

When a build has drifted off course, the temptation is to keep going. Sunk cost is the loudest voice in the room. The harder question is whether the system in front of you is worth saving — and what saving it actually means.

Three honest options

On a Forge: Repair triage we always start with three options on the table: repair, rebuild, retire. Saying any of them out loud changes the conversation. Most stakeholders default to one without considering the others. The framework forces a real comparison.

Repair when…

The architecture is broadly sound, the team understands the codebase, and the issues are concentrated in a few well-defined modules. Repair is faster and cheaper than rebuilding, but only if the foundation will hold under the next year of pressure.

Rebuild when…

The cost of repair approaches the cost of starting again, the original architecture won’t support what you need next, or the original team is gone and the codebase is undocumented. Rebuilding is expensive but sometimes the cheapest path forward.

Retire when…

The system no longer serves the business it was built for. We rarely arrive at this answer, but when we do, it saves the client more money than any rebuild would. A clean retirement plan is a deliverable in its own right.

How we decide

A two-week deep-dive: read the code, run it, talk to the people who use it, talk to the people who built it, write the three options up with costs, risks, and a recommendation. The recommendation is honest even when it’s inconvenient.