Hire engineers to audit your code

A report you can act on and hand to your board: an overall score, findings grouped by quality, security, architecture, tests and documentation, each with the file it lives in and an estimate of what leaving it alone costs. Then a call where we walk you through the three things worth fixing first. We do not deliver a list of three hundred lint warnings and call it an audit.

Both a tool and a person. We run our own audit bot across a repository first — it is scheduled against dozens of repositories in our own estate, on GitHub and Bitbucket, and it scores every run out of ten. Then an engineer who maintains production systems reads what the bot flagged plus the parts it cannot judge: whether the architecture matches what the business is about to ask of it. The bot finds the symptoms, the engineer works out which ones matter.

A week for a typical codebase, two if it is large or split across many services. We need read access to the repository, and half an hour with someone who can explain what the product is supposed to do — an audit without that context grades style instead of risk.

Yes, and it happens. The more common outcome is a middling score with two or three genuine risks, because that is what working software looks like once it has shipped for a few years. A first audit rarely comes back above seven out of ten, including the ones we run on our own repositories — we publish those internally with the same scoring, which is how we know what a realistic number looks like.

We can, and we will say so plainly rather than pretending the audit is neutral advice. It is also a legitimate outcome to take the report to your own team, or to another vendor. If you would rather we had no stake in the answer at all, say so before we start and we will price the audit as the only deliverable.