Someone senior,
actually reading it.
A codebase audit is the cheapest decision you can buy. Senior engineers read the code you have inherited — the tests, the data model, the commit history, the accounts you may or may not own — and hand you a written keep, fix, or cut with the reasoning behind each call. Useful whether the build has stalled, a vendor has gone quiet, or you are simply about to be read by somebody else’s technical reviewer.
What we read
Not a linter report. Five questions that decide whether the thing in front of you is worth continuing.
Can it be changed safely
Test coverage on the paths that matter, whether the build is reproducible from a clean machine, and how much of the system one person has to hold in their head. This is the question underneath every other one.
The data model
Sound data under messy code is recoverable. A confused data model is the expensive kind of problem, and it is the one most likely to force a rewrite — so we look here early rather than late.
What the history knows
The commit log is the only honest record of how something was built. Hotfix clusters, abandoned branches, the file every change touches, the tests that were deleted rather than fixed — all of it is on the record.
Release and operations
How code reaches production, whether it can be rolled back, and whether anyone finds out before your users do. A team that cannot ship safely ships rarely, which is usually the real reason a roadmap has stalled.
What you actually hold
Repository ownership, cloud and store accounts, domains, third-party keys, and whether the contract assigned the IP. On inherited projects this is frequently shorter than anyone believed.
What you get
A document, not a
conversation.
A conversation is easy to be optimistic in. What you get is written down, so you can disagree with it, take it to a board, or hand it to whoever builds the next part.
- Keep, fix, or cut — area by area, with the reasoning, not just the verdict
- The risks in priority order, including the ones nobody has named out loud
- An honest read on whether a rewrite is genuinely warranted
- What you actually hold: repositories, accounts, keys, IP
- A plan with a real estimate against it
- Yours to keep, whoever you end up building with
How it runs
You are not managing this. It costs you a kickoff, a couple of questions, and the reading of it.
Access, then read
A short kickoff to establish what exists and what you are worried about. Then senior engineers get the project running from a clean machine, walk the history, and map the architecture as it actually is rather than as it was intended.
Write it down
The findings become the memo: verdict per area, reasoning, prioritised risks, and options with estimates. We walk you through it, you push back, and the document goes to you in its final form.
Your call
Continue with us and the fee comes off the first month. Take it to someone else and it still does its job. Do nothing for a quarter and it is still an accurate account of where you stood — which is more than most teams have.
Common questions
What is a codebase audit, in practice?
Senior engineers read the code, the commit history and whatever documentation survived, then write down what they found: what works, what is salvageable, what has to go, and what each option would take. It is a decision document, not a score out of ten.
Do you need the original developers?
No. Most of the audits we run are on code whose authors are gone, unreachable, or no longer speaking to the client. If they are available and willing, a thirty-minute call helps; it has never been a requirement.
What if we only have partial access?
Bring what you have. A repository without deploy credentials, or a running app with no source, is still worth reading — and establishing exactly what is missing is one of the more valuable things the audit produces.
Will you tell us to rewrite it?
Rarely, and not without showing our reasoning first. Code that is unloved is not the same as code that is wrong, and a rewrite is the most expensive way to find that out. When we do recommend one, you will see why before you see the recommendation.
Is this useful if we are not in trouble?
Yes — two common cases. Before raising, because your codebase is about to be read by someone acting for an investor. And before scaling a team, because the cost of onboarding onto an undocumented system is paid once per hire.
Is the audit useful if we do not continue with you?
That is the intent. The memo is yours to keep and is written to be handed to another supplier, a new hire or a board. We would rather be judged on it than have it lock you in.
Find out what
you’re holding.
Tell us what you’ve inherited. It goes straight to Harley and Jonathan, not an SDR, and you’ll get a real reply within 24 hours — including an honest no if an audit isn’t what you need.
How a full rescue works → · Free 2-minute assessment → · Keep, fix, or cut →