Capabilities / Audits
You have the software.Nobody can tell you if it is sound.
It works, mostly. It was built quickly, or by an agency that has gone quiet, or by somebody who has since left, or by a tool that wrote most of it for you. Now it is carrying real customers and real money, and there is nobody left who can say what happens when it stops.
Placeholder
Two pages of a real report go here, redacted: the findings, the risk ranking, and the things we said to leave alone.
We read itbefore we judge it.
Most opinions about somebody else's software are formed in ten minutes from the outside. Those opinions are usually that it should be rebuilt, and they are usually wrong.
We go through what is actually there
The code, the infrastructure, the data and the dependencies. Not a look at the screens and a guess at what is behind them.
We ask what happens when it goes wrong
Backups, error handling, who gets woken up, and what the last outage cost. Most of what makes software risky is invisible while it is working.
We say what we would leave alone
Plenty of what looks alarming is fine, and replacing it would cost money for no gain. A report that recommends everything recommends nothing.
What we look at
Three reviews. Often more than one.
Most people arrive asking for the first. It is regularly the second or third that turns up the thing that was actually going to hurt.
Code and architecture review
How it is built, how it holds together, and what it would take to change. Whether the next feature is a week or a rewrite, and whether anybody but its author can work on it.
Compliance and security review
Where the data goes, who can reach it, what is out of date, and what would happen if somebody looked. The questions your first enterprise customer will ask you in writing.
User experience review
What people actually do with it against what it assumes they will. Where they stop, where they guess, and which of those is costing you the most.
A report you could handto somebody else.
The problem with an audit is obvious: the people doing it would like the work it recommends. Everything here exists to make that not matter.
Four things are true of every one:
It is written down
Not a call and a set of impressions. A document with findings, evidence and an order of play, which you still have in six months when the argument comes back.
Ranked by risk, not by preference
What could take the business down, what will cost you later, and what is merely untidy. In that order, and clearly separated.
It says what to leave alone
Explicitly. Anything we think is fine is named as fine, because a list of only problems tells you nothing about proportion.
It is yours
Take it to your own developer, to another agency, or to a buyer doing due diligence. We are not the only people who can act on it, and we do not write it as though we were.
How it works
Short, and mostly out of your way.
A typical audit looks like:
One call
What it does, who built it, how long it has been running, and what specifically you are worried about. That last one usually points at the right review.
Read-only access
The code and the hosting, and half an hour with whoever knows it best if that person still exists. Nothing changes and nothing is deployed.
A report, then a conversation
A week or two later, in writing, followed by an hour going through it. Ask whatever you like in that hour, including whether we would take it on.
When you are ready
Show us what you have.
Tell us what it does, who built it, and what is worrying you. We will say whether an audit is worth doing at all, and which of the three it would need.
Before you ask
The questions we always get asked.
Most of it was written by AI. Is that a problem?
Not by itself, and it is increasingly common. AI-written code tends to work and tends to be shallow: it is often fine on the happy path and thin on everything else - errors, edge cases, security, and the structure that lets somebody change it later. That is a knowable list rather than a mystery, which is exactly what an audit is for.
Are you going to tell me to rebuild it?
Sometimes, and we will say why in terms you can check. More often the answer is that parts of it are fine, one part is genuinely dangerous, and the sensible move is much smaller than a rebuild. If we thought everything needed rebuilding we would not have written the third of the four standards above.
Do you need the original developer?
No. It helps if they are still around and willing, and half an hour with them saves us a day. But the common version of this is that they are not, which is usually the reason somebody is asking for an audit in the first place.
How long does it take?
One to two weeks for most systems, and most of that is us reading rather than you doing anything. Larger or older systems take longer and we will say so before you commit rather than afterwards.
What does it cost?
A fixed fee, and we will tell you what it is on the first call once we know the size of the thing. It does not move afterwards.
If we want the work doing, do we have to use you?
No, and the report is written on the assumption that you might not. Plenty of audits end with a client handing it to the developer they already have, which is a perfectly good outcome and one we would rather have than an awkward project.
No pitch, no deck
Tell us what isactually happening.
Describe the mess in your own words. We will say what we think is going on underneath it, and whether there is anything we could usefully do about it.
Unovo LimitedSteel City Stadium, Olympic Legacy Park
Worksop Road, Sheffield S9 3TL
Registered in England and Wales, company no. 16375453