A software audit written for the person paying for it.
Most code audits are written for other developers. This one is written for you: what is wrong, what it could cost, who should fix it, and how you will know it is done.
You are probably here because of one of these.
- You are about to sign a larger contract, or renew one.
- A key developer has resigned, or you suspect they might.
- Deadlines keep moving, and the reasons keep sounding plausible.
- You are switching agencies, or bringing the work in-house.
- An outage surprised you, and nobody could say how long recovery would take.
- Your team uses AI tools, and you cannot tell whether that is helping you or them.
What we look at.
We choose from these against what is worrying you, and write down what we deliberately left out. Nobody needs all of it.
Do you own what you paid for?
Code, domains, cloud accounts and credentials in your company's name, and signed IP assignment from everyone who wrote code.
Would you survive losing one person?
How many people can release and restore each system, and where the knowledge actually sits.
Is it built the way you were told?
The system as it is, compared with the system as it was described to you.
Could you recover from a bad day?
Whether backups have ever been restored, and how long recovery would really take.
What could hurt you, and what would it cost?
Access, security basics and data protection, each with a figure attached.
Is AI being used safely, and well?
Whether your code leaves the building, and whether the time AI saves shows up on your invoice.
Every finding arrives with the fix attached.
It tells you what it means
A code review tells a developer what to change. An audit tells the owner what the finding costs and what to do first.
It shows how much we could see
We read your systems directly wherever you can give access, and print how much of the evidence came from the people we were reviewing.
Your team answers first
Anything that concerns them is put to them before it reaches you, and their reply is printed whether or not it changes the finding.
What you receive
- A one-page decision sheet: the answer, the risks, and the one thing to do this week
- What you should expect, what you were told, and what we found, side by side
- A plan where every fix has an owner, an effort and a way to prove it is done
- The questions to ask your team, with what a good answer sounds like
Imagine receiving a report like this.
Most people read one page, so page one carries everything that matters: the risks, what each could cost, who fixes it, and what you can stop worrying about. The rest is the evidence behind it.
PDF, five pages. A fictional business; every figure illustrates the format.
Before you book.
Do I need to understand code?
No. The report is written for someone who pays for software and cannot read it. Every finding says what it means for the business before it says anything technical.
Will my developers see the report?
They see the findings that concern them before you do, and they can reply. Their reply is printed in the report. It catches our mistakes early, and it stops the audit reading as an attack on the team.
What access do you need?
Read-only access wherever you can give it: the code repository, the cloud account, the task tracker. Where access is not possible we work from documents and say so in the report.
What happens to our code and data?
Access is handed back at the end. Source code extracts are destroyed when the engagement closes, and nothing you share is used to train any AI model.
What if nothing is wrong?
Then the report says so, and tells you what you can stop worrying about. Sometimes the thirty-minute call is enough, and we say that too.
How is it priced?
A fixed fee for a fixed scope, quoted after a thirty-minute call and set against what you spend on development.
Tell us what is worrying you.
Thirty minutes, no preparation, no charge. We work out what you actually need, scoped and priced fairly against your development budget. Sometimes the answer is nothing, and we say so.
