Code Audit Services
A fixed-scope, independent assessment of a codebase. Commissioned before an acquisition, before committing to a new phase, when a project has stalled, or when you need to know whether what you paid for exists.
Discuss your projectWhat we examine
Does it build from scratch
On a clean machine, from the repository, following whatever documentation exists. The first test and often the most revealing: a system that builds only on one person's laptop is a business risk regardless of code quality.
Security
Where credentials live, whether secrets are committed, how authentication and sessions work, whether access control is enforced server-side or only hidden in the interface, and the injection and object-reference classes of bug. The most consequential findings are usually here.
Dependencies
How far behind, which have known vulnerabilities, and which are abandoned. An unmaintained dependency is a future rewrite on someone else's timetable.
Architecture and data model
Whether the structure supports what you want to build next, or whether every change requires touching everything. The data model is the expensive thing to have got wrong.
Tests and CI
What coverage exists, whether it is meaningful, and whether it runs automatically. Usually the clearest indicator of how the project was actually run.
Operations
How it deploys, whether it can be rolled back, whether backups exist and have ever been restored, and what monitoring is in place.
Key-person risk
How much of this can only be changed by one person, and what is documented nowhere. Frequently the finding with the largest business consequence.
What is actually finished
Measured against what you were told. The section clients read first.
How the report is written
Findings are ranked by consequence and by cost to fix, with the risk of leaving each one stated. Ranking is what makes a report actionable — an unordered list of forty observations gets filed and nothing changes.
Every finding is specific enough to verify and specific enough to argue with. "The code quality is poor" is not a finding. "There is no automated test coverage, and the authorisation check on the invoices endpoint exists only in the front end, so any authenticated user can retrieve any invoice by changing the ID in the URL" is a finding: another developer can confirm it in ten minutes, and so can the developer who wrote it.
We also say what we did not examine, so the limits of the assessment are explicit. An audit with an unstated scope invites the reader to assume more coverage than it had.
Where we recommend a rewrite, the reasoning is set out in full and we state what continuing would cost instead — because carrying on is sometimes the right commercial choice even when it is not the right engineering one. A rewrite is the most profitable thing we could recommend, so you should expect the argument in writing and we would encourage a second opinion.
When people commission one
- Technical due diligence before acquiring a company whose product is software, where the codebase is a material part of what you are buying.
- Before committing budget to a significant new phase, to check the foundation will carry it.
- When a project has stalled and the explanations have stopped being convincing.
- When changing developer, so the incoming team starts from facts rather than from the outgoing team's account.
- When an investor or board has asked for an independent technical assessment.
- After an incident, to find out what else shares the weakness that was exploited.
- When you suspect you have paid for more than was delivered and need a factual account.
Common questions
Tell us what you need
Describe the problem and we will come back with scope, timeline, and a rate. No obligation to proceed.
Get in touch