What a technical code audit includes, and what drives its cost

A technical audit answers a simple question: what is the real state of this software, and what should we do about it? Founders ask it before investing further, buyers ask it before an acquisition, and teams ask it when a product built by someone else lands on their desk.

This article explains what a useful audit contains, how it is done, and what makes one bigger or smaller.

What you should get

The deliverable is a written report, not a slide deck of opinions. A useful report contains:

1. A summary for non-engineers. One page: overall health, the three to five most important risks, and what to do first.
2. Architecture overview. How the system is built: components, data stores, external services and how they talk to each other, with a diagram.
3. Findings, each with evidence. Every finding names the location in the code or infrastructure, explains the risk in plain terms, and rates severity.
4. A prioritised action list. What to fix first, with a rough effort estimate per item, so you can plan and budget.
5. What is good. Strengths to keep. A report that only lists problems is less useful, because it does not tell you what to protect.

What gets examined

A typical audit covers:

• Code quality and structure. Is business logic separated from frameworks and databases? Is the code consistent? Where are the hotspots that change often and break often?
• Tests. Do tests exist, do they run automatically, and do they cover the parts that matter? Test coverage numbers alone say little; we look at what is actually protected.
• Security. Dependencies with known vulnerabilities, authentication and authorisation, input validation, secrets in the code or repository, and how personal data is stored.
• Dependencies and platform. Supported versions of the language, framework and database; abandoned libraries; licences.
• Data model. Whether the schema matches the business, indexes, migrations, and data integrity.
• Performance and reliability. Slow paths, resource usage, error handling, logging and monitoring, backups and whether restores have ever been tested.
• Delivery process. How code gets from a developer to production: version control, code review, CI/CD, environments and documentation.

How it is done

1. Kick-off. A short conversation about the business, the goals of the audit and known problems. This decides where to look deepest.
2. Access. Read access to the repository and, if possible, to logs, monitoring and a non-production environment. No production write access is needed.
3. Analysis. Automated tools (static analysis, dependency scanning) give a broad picture; manual review of the most important paths gives the real one. Tools find symptoms; reading the code finds causes.
4. Interviews. If a team exists, a few conversations explain why things are the way they are. Context changes the recommendations.
5. Report and walkthrough. We present the findings and answer questions, so the report leads to decisions.

What drives the size of an audit

We price audits as a fixed scope agreed upfront. The factors that make an audit bigger or smaller are:

• Size and number of codebases. One web application is different from a platform with mobile apps, several services and a data pipeline.
• Depth. A health check of architecture and risks is faster than a line-by-line security review.
• Specific questions. "Can this scale to ten times the users?" or "Is this ready for a SOC 2 audit?" each add focused work.
• Availability of context. Documentation and a team to talk to make an audit faster; archaeology makes it slower.
• Infrastructure in scope. Reviewing cloud configuration and deployment adds to code review.

Be careful with audits that are very cheap and very fast. Running a scanner and exporting its output is not an audit; the value is in judgment about which findings matter for your business.

After the audit

The report should be usable by any competent team, not only by the auditor. Common next steps are:

• fixing the critical security and data risks immediately
• getting onto supported versions of the language and framework
• adding tests around the most important and most fragile code
• planning larger changes, such as the refactor-or-rewrite decision, with the evidence in hand

Our technical consulting service offers fixed-price audits with a written report and a prioritised action list. Doing the follow-up work with us is optional.