When to rebuild versus refactor.

Rebuilds are glamorous. Refactors are cheaper. The wrong choice wastes six figures and a quarter. Here are the three questions we use.

1. Is the architecture wrong, or is the implementation wrong?

If the bones are right — the data model, the boundaries, the service shape — you’re refactoring. If the bones are wrong, you’re rebuilding. Bad implementation on a good architecture can be fixed incrementally. Bad architecture on a good implementation cannot.

2. Is the team’s knowledge in the code, or in their heads?

If three senior engineers left and the system still makes sense, refactor. If the system only runs because two people remember how to deploy it, rebuild.

3. Is the next year of work additive, or redirective?

If you’re adding features on top, refactor. If you’re pivoting the product category, rebuild. Pivots don’t survive in systems shaped for the previous product.