Code audit checklist: seven things we check before we quote

We won’t quote on a codebase we haven’t read. Someone hands you a product that already exists and asks what three new features will cost. The feature list barely matters. What the estimate depends on is the state of what’s already there.

So before we price work on software we didn’t write, we run a short code audit: read access, a few hours, and seven checks. Each check answers the same question from a different side. How much will every future change cost in this codebase?

None of it is about style. Nobody is marking your variable names. What moves the number is friction that repeats: a setup that eats three days, a test suite nobody trusts, a deploy only one person knows how to do. You pay that cost on every task, until someone fixes it.

What is a code audit, and how is it different from a code review?

A code audit reads the whole codebase at one point in time to judge its condition. A code review reads one change before it’s merged. Reviews keep a healthy project healthy, one pull request at a time. An audit tells you what state the project is in right now, which is exactly what anyone quoting on it needs to know.

The seven checks

1. Can it run from a clean checkout?

The first test is whether a new machine can get the thing running from a fresh clone, following whatever documentation exists. If that takes an afternoon, the project is in reasonable shape. If it takes three days of asking the previous developer which environment variables are missing, every future task carries that same tax.

2. What does the commit history say?

Not the code, the history. Long gaps followed by single enormous commits usually mean work happened somewhere else and got pasted in. Thirty commits in a row named “fix” usually mean debugging in production. A steady history with readable messages tells us someone was paying attention, and that matters more than the framework choice.

3. Is anything tested, and does it pass?

We’re not looking for high coverage. We’re looking for whether tests exist at all, and whether they pass today. A suite that has been failing for months is worse than no suite, because the team has learned to ignore a red build. Michael Feathers put it bluntly in Working Effectively with Legacy Code: “Code without tests is bad code. It doesn’t matter how well written it is.” Without tests, changing anything means checking by hand everything it touches, and that time goes into the estimate.

The feature list tells us what you want. The codebase tells us what it costs.

4. How is the data shaped?

Schema problems are the expensive kind, because they spread. If the same information is stored in three places and kept in sync by application code, every new feature has to remember all three. If there are no foreign keys, we assume some of the data is already inconsistent and plan for cleanup.

5. Are the dependencies still supported?

We check what’s pinned, how old it is and whether anything has been abandoned. A framework or runtime past its end of life is a scheduled cost, not an optional one. Node.js, for example, states that a version at end of life no longer receives updates, including security patches. Sooner or later something forces the upgrade at the worst moment, so we’d rather price it now than find it halfway through.

6. What happens on deploy?

If deploying means someone copying files onto a server over SSH, nobody can ship safely or often, and everything slows down. If there’s a pipeline, a staging environment and a way back, we can move quickly. Google’s DORA research measures delivery by exactly these things: how often a team deploys, how long a change takes to reach production, and how fast it recovers from a failed deployment. Deployment isn’t a side concern. It sets the pace of the whole engagement.

7. Where are the secrets?

Credentials committed to a repository are common. GitGuardian’s State of Secrets Sprawl 2026 counted 28.65 million new hardcoded secrets in public GitHub commits in 2025, and found internal repositories roughly six times more likely than public ones to contain them. Finding them changes the first week of work. GitHub’s own guidance is that the first step is to revoke or rotate every exposed key; rewriting the history comes after, if at all. We’d rather find that before quoting than explain it afterwards.

The code audit checklist on one page

Here’s the whole thing, with what a good answer looks like and what a bad one does to the quote.

What you get at the end of the code audit

Two things. A number we can hold to, because it was made knowing what’s actually there. And a short written list of what we found, which you get whether or not you hire us.

That second part is deliberate. If the honest answer is that your codebase needs three weeks of stabilising before any feature work makes sense, you should hear it while you can still decide what to do about it.

What this checklist doesn’t cover

This is a pre-quote read, not a security audit or a penetration test. We flag what we see, like committed keys or an unsupported framework, but a few hours of reading won’t find every vulnerability. If you need a formal security review, or technical due diligence for an investor, that’s a separate job with its own scope.

Send read access and a rough scope. You get the seven-point read back before anyone talks money. Start here.

Sources

1. GitGuardian, “The State of Secrets Sprawl 2026”, 17 March 2026.
2. GitHub Docs, “Removing sensitive data from a repository”.
3. Node.js, “End-Of-Life”.
4. DORA, “DORA’s software delivery performance metrics”, updated 5 January 2026.
5. Michael C. Feathers, Working Effectively with Legacy Code, Prentice Hall.