What a good audit actually looks like
A 200-page PDF is not an audit. Here's the format we use when a client asks us to look under the hood.
Founder
Integrity Tech
When clients ask for an audit they usually mean one of three things: I'm about to invest a lot in this codebase and want a sanity check, I just inherited it and don't know what I have, or something is wrong and I can't tell what. The format of the audit changes based on which one it is.
The deliverable is a decision, not a document
Every audit we deliver ends with three things: a one-page summary written for the person paying for it, a prioritized list of actions, and an honest read of which actions are worth doing and which aren't.
We score what we can measure
- Core Web Vitals against real-user data, not lab tests.
- Test coverage by criticality, not by line count.
- Mean time to recovery from the last 5 incidents.
- Deploy frequency, lead time, change failure rate (the DORA four).
We tell you what to stop doing
Audits that only recommend additions are useless — every team already has more ideas than capacity. The best recommendation is usually a deletion: a service to retire, a process to skip, a tool to replace with a smaller one.
“A 200-page PDF is not an audit. It's an excuse to bill for two months.”