Audit, refactor or rebuild?
Rebuilds get chosen far more often than they are justified, because a clean repository feels faster than untangling an existing one and the cost is front-loaded where nobody sees it. Here is how to tell which path you are actually in, and the four signals that genuinely justify starting again.
Get it answered in 5 days
Five paths, not two
“Fix or rebuild” is a false binary, and the framing itself pushes teams toward rebuilding. There are at least five options between them, and the middle three are where most codebases actually belong.
| Path | Time to value | Risk | Choose it when |
|---|---|---|---|
| Audit first | Days | Very low. Read-only, nothing ships | You do not yet know how bad it is |
| Stabilise | Days to weeks | Low. Targeted fixes, existing behaviour preserved | A few specific things are broken and you know which |
| Refactor in place | Weeks to months | Medium. Behaviour must be preserved while structure changes | The shape is wrong but the domain logic is sound |
| Incremental replacement | Months, but shipping throughout | Medium. Two systems live at once, routed piece by piece | You need to keep shipping while replacing the foundation |
| Full rebuild | Months, with nothing shipping | High. You re-learn every requirement the old system encoded | The platform itself cannot support where you are going |
Time and risk describe relative effort, not a quote. Which path fits depends on the specific system, which is what an audit establishes.
Four signals that justify a rebuild
None of these is "the code is bad". Bad code is common and fixable. These are the conditions under which fixing it in place stops being the cheaper option.
The platform is the constraint
Not "the code is messy" but "this database, framework or hosting model cannot do the thing we now need". Messy code can be cleaned in place. A wrong foundation cannot.
Change cost is rising, not flat
A codebase that is ugly but where features still take about as long as they did six months ago is not an emergency. One where every change takes measurably longer than the last is compounding, and compounding beats tidying.
Nobody can predict the blast radius
When your team genuinely cannot say what a change will break, you have lost the ability to estimate. That is a different problem from technical debt, and it is the one that most often justifies replacement.
The requirements are known
The strongest argument for rebuilding is also the least discussed. You now understand the problem far better than whoever started. A rebuild is only cheap when the specification is already in your head, and expensive when the old system is the only place it is written down.
The cost nobody estimates
A rebuild estimate covers building the thing you can describe. What it misses is everything the existing system knows that nobody wrote down: the edge cases, the client-specific behaviours, the reason one field is nullable and another is not.
That knowledge is real, it is load-bearing, and the only place it exists is in code somebody is proposing to delete. It gets rediscovered during the rebuild — normally in production, normally because a user reports it.
This is why rebuilds overrun so consistently, and why the strongest argument for one is that you now genuinely understand the problem. If the specification lives in your head, a rebuild is cheap. If it lives only in the old system, you are about to pay to learn it twice.
Where an audit helps, and where it is the wrong purchase
Worth auditing first if…
- You are weighing a rebuild and the argument for it is mostly a feeling that the code is bad.
- Your team disagrees about the answer and nobody has evidence either way.
- You inherited the codebase from an agency, contractor, or AI tooling and cannot assess it yourself.
- A rebuild would mean a shipping freeze you are not certain you can survive.
Skip the audit if…
- You already know the platform cannot do what you need, and that answer is settled, so spend the money on the work.
- The system is small enough that a senior engineer could read all of it in a day. Just read it.
- You are rebuilding for reasons that are commercial rather than technical. That is a legitimate call and an audit will not change it.
- You have already committed and cannot reverse the decision. An audit then is an expensive second opinion on a closed question.
Questions behind the decision
Fix it, unless the platform itself is the constraint. Rebuilds are chosen far more often than they are justified, because a fresh repository feels faster than untangling an existing one, and because the cost of a rebuild is front-loaded and invisible at the decision point. The honest test is whether the current foundation can technically support where you are going. If it can, the problem is structure, and structure can be changed in place while the product keeps running.
Get the answer in five days
A senior engineer reads the whole system and tells you which of the five paths you are actually in, with the evidence for it. $4,999, fixed. If the answer is that your code is fine, we will tell you that too — it is the cheapest outcome we can hand you.