Capabilities / Audits
Know what you’ve gotand what’s broken.
Your software may be working perfectly well. But once the business depends on it, it is worth knowing what is really going on underneath. We look at the technology you rely on and give you a clear, independent view of what is working, what needs attention and what to do next.
We read itbefore we judge it.
It is easy to look at somebody else's software and decide you would have built it differently. That does not mean there is anything wrong with it, so we take the time to understand what is actually there before we recommend changing anything.
We understand what is there
The code, the infrastructure, the data and the dependencies. Not just what you can see on screen.
We find what matters
Security, reliability, performance, and how easily it can keep being developed. Most of that is invisible from the outside, so we look for it directly.
We say what we would leave alone
Not everything needs fixing. We separate genuine problems from things that are simply untidy, unconventional, or not how we would have built them.
What we look at
Look at it from every angle.
Each one answers a different question about the same system. Most people start with one, and we will tell you if another is worth adding.
Code and architecture
Can we keep building on it? How the software is structured, how maintainable it is, where the technical debt sits, and what it will take to keep developing.
Security and compliance
Is anything putting us at risk? How your systems and data are protected, who has access, what is out of date, and where security or compliance needs attention. The questions your first enterprise customer will ask in writing.
User experience
Is it working for people? How customers and your team actually use it, where they struggle, and where better design would take the friction out.
A reportyou can use.
An audit should leave you knowing what to do next. We give you a clear, prioritised view of what we have found, backed by evidence and written so that whoever looks after your technology can act on it.
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 question comes up again.
Ranked by risk, not by preference
What needs attention now, 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
Straightforward, and mostly out of your way.
A typical audit looks like:
One conversation
Tell us what the system does, where it came from and anything you would particularly like to understand. We will work out where to focus.
Read-only access
The code, the hosting and anything else relevant, plus half an hour with whoever knows it best. Nothing changes and nothing is deployed.
A report, then a conversation
Our findings in writing a week or two later, followed by an hour going through what matters and deciding what happens next.
When you are ready
Want a second opinion?
Tell us a little about the software and what you would like to understand. We will tell you whether an audit would be useful, what we would look at and what it would cost.
Before you ask
The questions we always get asked.
Most of it was written by AI. Is that a problem?
Not necessarily. AI-assisted development is increasingly common, and what matters is the same as for any code: whether it is secure, whether it can be maintained, and whether it is structured so somebody can keep building on it. Those are knowable things, and finding them out is exactly what an audit is for.
Are you going to tell me to rebuild it?
Only if we genuinely believe it is the most sensible option, and we will explain why in terms you can check. More often we find a mixture: things that are working well, things worth improving, and a smaller number that need proper attention. The report makes that distinction clear.
Do you need the original developer?
No. It helps if they are around, and half an hour with them can save us a day, but plenty of audits happen without them and the report is written so it does not depend on them.
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. The report is written so that whoever looks after your software can act on it, and plenty of clients take it to the developer they already have. If you would like us to do the work, we are happy to talk about that too.
Keeping you in the loop on the technology changing how work gets done.
Read our hot takes on the technology changing how people work, and find out a bit about the nerdy things our team have been doing.
Read the latest issueNo pitch, no deck
Tell us what isactually happening.
Describe the problem in your own words. You do not need it worked out first - an honest conversation usually gets further than a tidy brief.
Unovo LimitedSteel City Stadium, Olympic Legacy Park
Worksop Road, Sheffield S9 3TL
Registered in England and Wales, company no. 16375453