What We Actually Do in a Technical Audit

"Can you take a look at our codebase" is one of the most common ways an engagement with us starts. It's also one of the easiest requests to do badly — a rushed audit produces a list of complaints, not a plan. Here's what a real one looks like.

Week one: read before you judge

We don't touch a keyboard for the first few days beyond taking notes. We read the commit history, not just the current state of the code, because how a codebase got to where it is tells you more than the code itself. A messy authentication module that's been rewritten four times under deadline pressure is a different problem than one that was simply never revisited.

We talk to the engineers who work in the code every day before we talk to the people who manage them. The team living in a codebase knows exactly where the bodies are buried — they're usually just never asked directly.

Week two: separate the merely ugly from the genuinely risky

Every codebase has parts that are unpleasant to work in. Very few of those parts are actually dangerous. Our audit sorts every finding into one of three buckets:

• Cosmetic — inconsistent formatting, dated patterns, code that works fine but wouldn't be written that way today.
• Costly — code that works but measurably slows the team down, like a missing abstraction that gets copy-pasted every sprint.
• Risky — code that is one edge case away from a production incident: unguarded race conditions, missing input validation at trust boundaries, or infrastructure with no rollback path.

Only the third bucket gets prioritized ahead of feature work. The other two go into a backlog that gets addressed opportunistically, not a rewrite that halts the roadmap for a quarter.

The deliverable is a plan, not a verdict

We've seen audits that amount to a long list of everything wrong with a codebase, delivered with no sense of sequencing or cost. That's not useful — it's just anxiety with a table of contents. Ours ends with a prioritized, scoped plan that respects what already works, because most of what already works, works for a reason.