What a real technical audit finds (and why the greenfield answer is usually wrong)

# What a real technical audit finds (and why the greenfield answer is usually wrong) When a non-technical founder or ops leader inherits a codebase — through an acquisition, a team transition, or bringing on a fractional CTO to assess a beta someone else built — the instinct is almost always the same: rewrite it properly, on a modern stack, from scratch. That instinct is usually a mistake, and a real audit is what tells you why. ## The checklist a real audit actually runs A surface-level review reads the README and checks that the build passes. A real technical due-diligence pass goes further: - **Route/controller file size.** A single route file north of a few thousand lines is a reliable signal that logic accumulated without structure — not necessarily bad code, but code nobody has fully mapped in a long time. - **Dead dependencies.** ORMs, SDKs, or libraries that are installed and imported but no longer load-bearing. They cost nothing to leave, but they cost real time to someone diagnosing a bug who assumes they're active. - **Secrets in version control.** Committed credentials are one of the most common findings in an inherited codebase, and one of the cheapest to fix once found — the expensive part is finding it. - **What the deploy platform actually does with your data.** A specific, underappreciated one: some managed platforms seed every preview/PR environment by cloning production's environment variables. If nobody's checked, every pull request may be running against real production data without anyone deciding that on purpose. - **Whether the aspirational stack matches the actual stack.** Teams describe their system as "modern" based on what they *meant* to build, not what's actually deployed. A real audit reads the deployed code, not the pitch deck. ## The build-vs-buy decision an audit should actually inform The default move — "let's rewrite this on a clean modern stack" — has real appeal: no legacy debt, no archaeology, a clean mental model. But it also throws away every hour of production-tested behavior the existing system has already accumulated, and it takes on a new kind of risk: a rewrite that quietly fails to replicate edge cases the old system handled by accident. A real audit weighs this explicitly, with evidence: how bad is the existing codebase's structure, specifically — not vibes, a catalogued list of concrete issues? How much of the system's actual behavior is well-understood versus load-bearing tribal knowledge? Is there a way to prove a migration path preserves behavior before committing to it? That last question has a concrete answer: a **parity harness** — a regression test that runs the old and new systems side by side on real inputs and diffs the output. When it's possible to build one, and the outputs come back byte-identical across a representative sample, that's not a vibe — it's proof a migration preserved behavior exactly, which is a categorically stronger claim than "tests pass." ## The takeaway for a non-technical decision-maker You don't need to read the code yourself to make a good call here. You need someone who will hand you a specific, evidenced list — not a general impression — of what's actually wrong, what it would cost to fix in place versus rebuild, and proof (not assurance) that whatever path gets chosen doesn't quietly break what already works. That's what a real technical audit produces, and it's the difference between a build-vs-buy decision made on evidence and one made on instinct.