What a two-week audit tells you that six months of meetings will not
A third of our work is inheriting somebody else's codebase. Here is exactly what we look at, and how we decide extend versus rebuild.
Priya Raman
Principal Engineer, Web
"Should we rebuild or extend?" gets argued in meetings for months, usually by people with a stake in the answer. It is a two-week question with a factual answer, and the answer is "extend" far more often than anyone in the room expects.
What we actually look at
Test coverage on the domain layer, not overall. Overall coverage is a vanity number inflated by getters. What matters: if I change the pricing rules, does anything fail? A codebase with 30% coverage concentrated on business logic is far safer to extend than one with 80% spread evenly over everything.
Dependency age and reachability. Not just "how outdated" but "can this be upgraded at all". A Django 2.2 app on a maintained stack is a week of work. One on a framework whose maintainer disappeared in 2021 is a different conversation.
The build. Can a new engineer clone it and run it on their machine in under an hour, from the README? If not, every estimate against this codebase is fiction, because most of the cost is in the friction nobody has measured.
Data model coherence. This is the one that actually decides it. Bad code over a sound data model is a refactor. Sound code over a broken data model is a rewrite wearing a trench coat — the model leaks into every layer and you will pay for it forever.
Concentration of change. Git history, files by change frequency. If 80% of commits touch 6% of files, those files are the product and the rest is scenery. That is where the audit goes deep and where a rebuild would spend its time.
Production reality. Error rate, p95 latency, crash-free sessions, uptime. A codebase everyone hates that has run at 99.97% for two years is telling you something the code review will not.
How we decide
Rebuild if: the data model is fundamentally wrong for what the product now is, the stack is unmaintainable, or the concentrated-change files are beyond repair.
Extend if: the model is sound, tests exist where they matter, and the pain is concentrated in a small, replaceable area. Which is most of the time.
The honest bit
A rebuild is a much larger project for us. Recommending "extend" costs us money on every audit where it is the right answer, and it is the right answer roughly two thirds of the time.
We do it because the alternative — an eighteen-month rebuild that reaches feature parity in month twenty-two and reintroduces bugs the original fixed in 2021 — is how agencies lose clients permanently. Twice we have told a client their existing team should do the work and they did not need us at all. Both referred us to someone else within the year.
