What a codebase audit actually covers

An audit is the first thing we do on a takeover, and the only thing we do for some clients. It is fixed in scope, it produces a written report, and it is designed to be useful even if you never speak to us again.

What we read

• The repository: structure, dependencies, build, tests, and the last year of commit history.
• The deployment path: how a change gets from a laptop to production, and who can do it.
• The infrastructure: hosting, databases, queues, secrets, backups, and what happens when one of them fails.
• The critical workflows: the three or four paths that earn the business money, traced end to end.
• The data boundaries: what is stored where, who can see it, and what the privacy commitments say.
• The security exposure: authentication, authorization, input handling, and the dependencies with known problems.
• The performance risk: the queries and endpoints that will fall over first under load.
• The roadmap: what the business needs next and whether the system can carry it.

What you get

A written report with the risks ranked by likelihood and cost, the unknowns named as unknowns, and a plan in three parts: what to fix now, what to fix next, and what to leave alone. If we think the system should be replaced, we say so and we say why. Most of the time we do not.

What it costs you

Read access to the repository and the deploy target, an hour with whoever knows the system best, and one to two weeks of calendar time. You keep the report either way.