What Will a Code Audit Tell Me?

We inherited a codebase from an agency that's no longer around. Before we pay for new features, our board wants an audit. What would it actually look at, and what do we get at the end?

An audit reads the code as the next developer will have to: six areas, from its structure to who understands it. At the end you get a ranked list of fixes, each with its file, its change and its effort in days.

The ranking is the point. Any audit finds problems. A useful one says which to fix first, in business terms for the board and in files for the developer.

With the agency gone, nobody is left to explain why the code looks the way it does. So the audit has to read the history as well as the files.

Six Areas, in the Order They Hurt

An audit reads six areas, in the order they usually hurt. A good one starts from the symptom the team feels, a slow change or a bug that keeps coming back, and follows it into one of them:

• Structure: whether a change stays where it was made. Code built from swappable parts lets one piece change without dragging the rest.
• Data model: where state lives, and whether it can carry the next feature. With the stack, it costs the most to undo.
• Failure handling: what the system does when something goes wrong without an error. Six production bugs of mine logged success and delivered the wrong result.
• Scale and cost: what breaks first as users grow, and what gets expensive. My own RSS reader cost about $17 a month with one user, and four fixes took it to $0.75.
• Security at the seams: keys, database rules and every place one system talks to another.
• Continuity: whether the code lives in one head, and what the next developer finds on day one.

For this team, continuity is half answered already: the people who held the code left with the agency. The other five areas say what that loss costs.

The History Says What the Files Don't

Files show what the code does. The commit history shows how it got that way: Documentation counts it as the story of the project. For this team, it's the only explanation left.

git shortlog -sn counts commits per author, and git blame names who last touched each line. Together they show how many people wrote most of the code, and when the last of them stopped.

A zip of the code has no history, and that's a finding of its own. If the agency handed over bare files, nobody can see who wrote what or why.

The history names authors, not the owner of the rights. Only a contract settles that: Who owns the code my developer writes?

An AI Scan Catches Local Problems

Run an AI scan first. It reads file by file and catches local issues: an unsafe query, a missing check, a key in the wrong place. It's worth having before anyone is paid.

What no file says is where the money goes. A scan can't tell which module next quarter's roadmap will hit, or what has failed in production before. It can't say whose name the accounts sit under, what a fix costs, or whether anyone can still deploy.

For code an agency left, ask that one early: can anyone on the team deploy it at all? When only one person knew the release steps, the release left with them. Releasing without breaking things covers that path.

What You Get at the End

Three things, each with its own reader:

1. A ranked list of fixes for the developer, each with the file, the change and the effort in days, worst first.
2. A verdict on rewriting or refactoring, with each path's cost in weeks. Should I rebuild my app from scratch? covers that choice in full.
3. One page in business terms for the board: what the code can carry, what it risks and what fixing it costs.

A list without a ranking is a checklist, and most process audits end in one. Before you pay, ask whether the result is ranked, and by what.

The same read goes by other names, an architecture review among them. Technical due diligence runs it before money moves, because an investor or a buyer will open the repo too. A DevOps audit aims it at how the team ships, from an idea to production.

The difference is the question the result answers.

What an Audit Costs

Upwork job posts mark the low end. Among those open in October 2026, code audit jobs had a median fixed budget of $250, and taking over someone else's code $500.

At common freelance rates, that pays for a few hours, and a few hours is a skim. Every audit has a reason. It should answer one question, often with a yes or a no: can this code carry what the board wants next?

Answering it takes study. The code has to be read, launched and run locally, tested, and checked against what it's meant to do. That's days of work, not hours.

Fixes are priced on their own. The report should be clear enough that any developer can pick it up, so the team chooses who does the work.

How I Run One

Mine reads JavaScript and TypeScript code. It takes one week, with read access to the repo and the hosting accounts. My architecture audit ends in the ranked list, the verdict, the board page and the top fix as a pull request. The price is on the homepage.

The same week covers due diligence and a DevOps audit. Release fixes are work I've done: on one product team I helped, I turned a release of 16 manual actions into one Slack command, and the team released once or twice a day.

Fixes after it run by the week, with me or with whoever you choose. Stopping after the report is a normal ending, the way Exit Freedom describes.

What the Team Should Do Now

Get the audit before the features, as the board asked. Before it starts, collect access: the repo with its history, the hosting and database accounts, and the domain.

When it's done, send the one-page summary to the board and the ranked list to whoever does the work. Then fix from the top, one item at a time.

A code audit checks a lot of things. What it hands over is one: the next fix worth making.