Code Audit: What We Review, How We Work and What We Deliver

Inheriting a codebase is like buying a second-hand flat: the photos look great, but what matters is inside the walls. Wiring, plumbing, damp… In software, the "damp" is technical debt, vulnerabilities and architectural decisions nobody wrote down. And you find it the same way: by opening the wall.

A code audit is exactly that: opening the wall before you sign. Whether you're weighing up a refactor versus a rewrite, about to acquire a company for its product, or the team that built it is long gone. This guide explains what we review in a serious audit, how the process works and — most importantly — what you take away at the end: not a PDF for a drawer, but an actionable plan.

The Problem: Big Decisions with Small Information

The most expensive decisions about a software product are made with the worst available information:

• "Should we refactor or rewrite?" — answered in a meeting, from memory, by whoever talks loudest.
• "How much is the software of this company we want to buy worth?" — answered with a pretty demo and the revenue figures.
• "Why does every feature take twice as long as two years ago?" — answered with "the code is just really bad", which is not an actionable answer.

In all three cases the same thing is missing: objective evidence about the real state of the code. And gut feelings on these decisions are paid for in quarters.

What a Code Audit Is (and What It Isn't)

A code audit is a systematic, independent review of the state of a codebase, aimed at answering business questions: what risks does it carry? what does it cost to maintain? will it handle the planned growth? what should be fixed first?

And it's just as important what it isn't:

• It's not a glorified linter. Automated tools (static analysis, complexity metrics, dependency scanners) are the raw material — 20% of the work. The remaining 80% is judgement: reading the architecture, understanding why decisions were made and weighing their real impact.
• It's not a trial of the team. All code is a child of its context: deadlines, business pivots, teams that rotate. The audit evaluates the code, not the people — and a report used to point fingers is a failed report.
• It's not a report to file away. If it doesn't end in a prioritized backlog with quick wins and a roadmap, it's not an audit: it's a funeral.

The Six Dimensions We Review

No single dimension tells the truth on its own. An app can have wonderful tests on top of an architecture that won't scale, or clean code deployed on fragile infrastructure. That's why the review is always multidimensional:

1. Architecture: will the design hold up for the next two years of product? Coupling, module boundaries, real scalability, single points of failure. This is the dimension that costs the most to change later.
2. Code quality: readability, duplication, cyclomatic complexity, conventions. Not for aesthetics: because code quality is the most reliable predictor of the team's future velocity.
3. Security: the OWASP Top 10 as a starting point — access control, injection, secrets in the repo, vulnerable dependencies, data exposure. We detail it in our OWASP guide.
4. Testing: coverage yes, but value above all: do the tests catch real regressions or just provide a feeling of safety? Does the suite run in minutes or in hours? Are there tests in the right layers?
5. Infrastructure and deployment: CI/CD, reproducible environments, monitoring, tested backups (not "configured": tested), and how much of the deployment depends on one specific person.
6. Documentation and knowledge: can a new developer be productive in a week? Architecture decision records (ADRs), runbooks, and the "bus factor": what happens if the key person is gone tomorrow?

The Process, Week by Week

A typical audit takes two to four weeks depending on the size of the system, and coexists with the team without slowing it down:

1. Kickoff (day 1): scope the business question. Auditing for an acquisition is not the same as auditing to decide on a refactor. The question defines the depth of each dimension.
2. Access and automated analysis (week 1): read-only access to the repo, CI and metrics. We run the automated battery: static analysis, dependencies, coverage, git history (the files that change the most and have the fewest tests are gold).
3. Manual review (weeks 1-2): reading guided by the above: the hot modules, the system's edges, the critical business flows. This is where what no tool can see shows up.
4. Interviews (week 2): two or three short conversations with the team. "What are you afraid to touch?" is the most profitable question of the whole audit.
5. Report and presentation (weeks 3-4): written deliverable and a one-hour session with the business side and with the technical team, separately: each needs a different level of detail.

What a Real Finding Looks Like

The heart of the report is the findings, and every one follows the same format — without this, findings are just opinions:

SEV-1 | Security | IDOR on /api/invoices/{id}
  Evidence:    GET /api/invoices/1042 with another customer's
               token returns the invoice (missing ownership check)
  Impact:      customer data exposure (GDPR)
  Effort:      1 day (controller policy + tests)
  Action:      quick win — week 1

SEV-2 | Architecture | Domain-framework coupling
  Evidence:    214 domain classes reference the ORM
  Impact:      impossible to test the core without a DB; every
               framework migration becomes a project
  Effort:      4-6 weeks (gradual extraction, module by module)
  Action:      structural — plan for Q1

Severity, concrete (reproducible) evidence, business impact, estimated effort and an actionable recommendation. If a finding doesn't have all five, it doesn't make the report.

What You Take Away: The Deliverable

The report has three layers, designed for three different readers:

• Executive summary (2 pages): overall health per dimension, the 3-5 risks that matter and the strategic recommendation. For leadership, and to answer the original question: refactor or rewrite, buy or don't buy.
• Full technical report: every finding with its evidence, for the team that will carry out the fixes.
• Prioritized backlog: every finding on the impact/effort matrix — quick wins (high impact, low effort) in the first week, structural projects scheduled, and what honestly isn't worth touching.

The matrix is deliberately ruthless: if everything is a priority, nothing is. A good audit also tells you what not to do.

When It's Not Needed

• Young project with a stable team. If the code is a year old, the team knows all of it and velocity isn't decaying, the audit will tell you what you already know.
• You already have the evidence. If you measure quality, coverage, vulnerabilities and debt continuously (and act on it), a one-off audit adds little: you're already living in it.
• As a weapon. If the real goal is to justify getting rid of the team or the vendor, the report will be born contaminated — and the team will notice from the very first interview.

Common Mistakes

1. Auditing with automated tools only. A SonarQube PDF is not an audit: it's raw material without judgement or business context.
2. Not scoping the question. "Review everything" produces 80-page reports that answer nothing. The business question is the filter for everything else.
3. Leaving the team out. An audit behind the team's back creates resistance and, worse, throws away the best available source of information.
4. Prioritizing by technical taste instead of risk. The ugliest code isn't always the most dangerous: what matters is what breaks the business if it fails, not what hurts the eyes.
5. Filing the report away. The most expensive audit is the one that changes no decisions. If three months later nobody has executed a single quick win, the problem was never the code.

In Summary

A code audit turns gut feelings into evidence: six dimensions reviewed methodically, findings with severity and business impact, and a deliverable that ends in decisions — executive for leadership, technical for the team, and a prioritized backlog where quick wins come first. Big decisions about software are too expensive to make from memory.

If you're facing a refactor decision, an acquisition or a team that has lost velocity with no clear explanation, that's exactly the work we do: two to four weeks, without slowing the team down, with an actionable plan at the end. Let's talk about your case →

Keep reading: OWASP Top 10: the 10 critical vulnerabilities explained with real examples.