An Independent Audit of the Codebase You Have Inherited
A fixed-price, read-only review of a JavaScript, React or Node codebase, delivered as a written findings report. What is dangerous, what is merely untidy, what will break under growth, and what is genuinely fine and should be left alone.
Four Situations Where an Audit Pays for Itself
All four have the same shape: a decision is coming, and nobody in the room can describe the code it depends on.
A Team Is Handing Over
An agency contract is ending or a developer is leaving. You get one chance to find out what you are actually receiving, while the people who wrote it are still reachable and still answering email.
You Inherited a Codebase
The application works, it makes money, and nobody currently employed can explain how. Before anyone touches it, it is worth knowing where the load-bearing walls are.
You Are About to Invest in a Team
Hiring three developers into a codebase nobody has mapped is an expensive way to discover its problems. An audit is the cheaper first step, and it makes the brief far better.
Due Diligence Before an Acquisition
Technical diligence on something you are buying, or getting your own house in order before somebody does it to you. Either way, a written third-party assessment carries more weight in the room than an internal opinion.
A Verdict You Can Act On, Not a Tool Report
Anyone can run a linter and a dependency scanner over a repository and email you the output. That is not an audit, it is a list of warnings with no sense of which ones matter. The value is in the judgement: which of these findings would actually hurt you, in what order, and at what cost to fix.
So we read the code. We install it, run it, follow the important paths end to end, look at the commit history where it explains something, and talk to whoever is left who remembers why a decision was made. Automated tooling is part of the input. It is not the deliverable.
The audit is read-only and fixed-price. We do not open pull requests, we do not change your code, and the scope does not grow once we are inside.
Start with a scoping callWhat the Audit Actually Inspects
Eight areas. Not every one matters equally to every codebase, and the report says which ones mattered to yours.
Architecture
- How the application is divided, and whether those divisions still match what it does
- Where business logic actually lives, and how many places it lives in twice
- Coupling that will make the next feature expensive
- Data flow, and the places where two sources of truth disagree
Dependency Health
- Packages that are abandoned, unmaintained or have no maintained replacement
- How far behind the important dependencies are, and what upgrading each one would cost
- Duplicate and conflicting versions of the same library in one tree
- Licences that could matter if you are raising money or being bought
Security
- Authentication and authorisation, including the endpoints where the check is missing
- Input handling, injection surfaces and what is trusted from the client
- Secrets in the repository, in the build, or in log output
- Known vulnerabilities in dependencies, filtered down to the ones actually reachable
Test Coverage and Quality
- What is tested, what is not, and whether the tests assert anything meaningful
- Whether the suite is trusted by the team, which is a different question from whether it passes
- Flakiness, run time and where it sits in the workflow
- The paths that would hurt most if they broke and are currently uncovered
Performance
- Database access patterns, including queries running once per row
- Bundle size and what is being shipped to the browser that need not be
- Caching that is missing, and caching that is wrong
- The parts that are fine now and will not be at three times the traffic
Build and Deploy
- Whether a clean checkout builds and runs without tribal knowledge
- CI configuration, and what it actually verifies before something ships
- How a release happens, how it is rolled back, and who is able to do either
- Environment configuration, secrets management and what differs between environments
Documentation
- What exists, what is accurate, and what is confidently out of date
- Whether a new developer could get productive without an existing one beside them
- Decisions recorded nowhere, so nobody knows if a constraint is real
- API and integration documentation against what the code actually accepts
Bus Factor
- Which parts of the system exactly one person understands
- Code that only builds on one machine or deploys from one laptop
- Accounts, domains and credentials held by individuals rather than the company
- What your exposure actually is if a named person resigns tomorrow
What We Bring to It
- Senior developers who have maintained large JavaScript codebases, not junior reviewers with a checklist
- No interest in defending a decision, because none of them were ours
- A stated confidence level on findings where we are inferring rather than certain
- Plain language, so the report survives being read by someone who is not a developer
How Findings Are Categorised
Every finding carries a severity and an effort estimate, so the list can be read as a plan rather than a complaint.
Fix Before Anything Else
Exposed credentials, an endpoint with no authorisation check, data that can be lost with no backup path, a dependency with a reachable known vulnerability. Things that are a problem today rather than eventually. Each one comes with what it would take to close it.
Plan It Into the Next Quarter
The unmaintained package at the centre of the system, the untested payment path, the query that will fall over at three times the load, the release process only one person can run. Not on fire, and genuinely expensive to keep ignoring.
Improve When You Are Nearby
Inconsistent patterns, thin documentation, duplication that is annoying rather than dangerous, tests that could assert more. Worth fixing as you pass through the code, not worth a dedicated project of their own.
Leave It Alone
The parts that are fine. We say so explicitly, because "this is unfashionable but correct, do not let anyone talk you into rewriting it" is one of the more valuable sentences in an audit report, and it never appears in a tool-generated one.
Alongside the severity, each finding carries a rough effort band — an afternoon, a sprint, or a project — so you can see immediately which critical items are cheap and which important ones are not.
How an Audit Runs
Read-only from start to finish, with a fixed price agreed before the first line is read.
Scoping Call
Thirty minutes. What the system does, how big it is, why you are asking now, and what decision the report needs to support. We come back with a fixed price and what is in and out of scope. If we think an audit is not what you need, we say that here rather than after you have paid for one.
Access and Context
NDA signed, read access to the repository, whatever documentation exists however stale, and a commit reference so the findings refer to a fixed point rather than a moving target. We install and run the application ourselves, which is often the first finding on its own.
The Review
Senior developers read the code across the eight areas above, following the important paths end to end rather than sampling files at random. Automated tooling runs in parallel and feeds in as input, never as the conclusion.
Questions to Your Team
A short list of specific questions for whoever is still around: why this was done this way, what that service is for, whether this is deliberate. It separates decisions made for good reasons from accidents that ossified, and it is the difference between a fair report and a harsh one.
Draft Findings and Walkthrough
You see the findings before they are final, on a call, with the reasoning behind the severities. If we have misread something because we lacked context, this is where it gets corrected. Nobody is served by a report with an avoidable error in it.
Final Report and Priorities
The written report, yours to keep and to share with an investor, an acquirer or your board. It ends with a prioritised list: what to do first, what to plan for, what to ignore. Whether you then hire anybody, through us or otherwise, is entirely your business.
What an Audit Deliberately Does Not Do
Being clear about this up front is what keeps the price fixed and the findings honest.
It Does Not Change Your Code
- No pull requests, no refactors, no dependency bumps. Read-only from start to finish.
- Mixing assessment with repair is how a fixed scope quietly becomes an open-ended engagement.
- If you want the findings acted on, that is a separate, separately priced conversation — your team, a developer hired through us, or a scoped remediation.
It Is Not a Penetration Test
- We review code and configuration for security problems; we do not attack a running system.
- No production credentials, no live traffic, no attempts to exploit what we find.
- If the report suggests you need a formal penetration test or a compliance certification, it will say so and we will not pretend to provide it.
It Does Not Grade Your Previous Team
- The report is about the code, not the people who wrote it. Most of what we find was a reasonable decision under a deadline we were not there for.
- We will not write something designed to be used in a dispute, and we will tell you if that seems to be the intent.
- Where a decision looks bad but was probably right at the time, the report says that too.
It Does Not Recommend a Rewrite by Default
- A rewrite is almost always the most expensive answer and rarely the right one. See legacy modernisation for what we usually suggest instead.
- Where a rewrite genuinely is the right call, the report makes the case explicitly rather than implying it.
- "This is fine, spend the money on features" is a legitimate and reasonably common outcome.
You Get the Honest Verdict Either Way
We sell developers. An audit that manufactures a crisis would be an efficient way to sell more of them, and it is exactly why the verdict has to be independent of what happens next. A report written to create a project would be worth nothing to you and would be obvious within a month of somebody competent reading it.
So: you pay for the audit, you own the report, and you can hand it to your existing team, to another supplier, or to nobody at all. If the conclusion is that the codebase is in reasonable shape and you should spend the money on features instead, that is what the report will say.
If you do want the findings worked through, the natural next step is one or two developers who join your team and take the list in priority order — with the usual two-week replacement guarantee and no account-manager layer in between.
What Usually Follows an Audit
TypeScript Migration
When the report says the codebase is large, untyped and changing too carefully to be safe.
Learn moreLegacy Modernisation
Old frameworks, an unsupported Node version, abandoned dependencies — replaced route by route rather than rewritten.
Learn moreTesting and Automation
When the finding is that nothing is tested and nobody can change the code with any confidence.
Learn morePerformance Work
For the findings that are really one query, one bundle and one missing index wearing a trench coat.
Learn moreHire Full-Stack Developers
One or two people who join your team and work the findings list in priority order.
Learn moreAll Services
Every role and every piece of fixed-scope work, with what each one is genuinely for.
Learn moreQuestions About Code Audits
What do you need access to in order to run an audit?
Read access to the repository, and ideally the ability to install dependencies and run the application locally. Beyond that we want whatever documentation exists even if it is out of date, access to your CI configuration and deployment setup, and half an hour each with one or two people who know the history. Production credentials are not required and we would rather not have them. If your previous team has gone and nobody can answer questions, we can still run the audit from the code alone — it just takes longer to separate deliberate decisions from accidents.
How long does an audit take and how is it priced?
It is a fixed price agreed before we start, quoted in US dollars, with no hourly billing and no scope that grows once we are inside. The elapsed time depends on the size of the codebase: a single application is usually a matter of days, while a large multi-service estate runs to a few weeks. We scope it on a short call, tell you what the number is, and that is the number. If we think the audit is not what you need, we will say that on the same call.
Do we have to hire developers from you afterwards?
No, and the report says the same thing whether you do or not. You pay for the audit, you own the findings, and you are free to hand them to your existing team, to another supplier, or to nobody. We would obviously like the follow-on work, which is exactly why the verdict has to be honest — a report written to manufacture a project would be worth nothing to you and would be found out within a month.
Does the audit include fixing what you find?
No. An audit is read-only by design, and mixing assessment with repair is how a fixed scope stops being fixed. What you get is findings, each with a severity, an estimate of effort and enough detail that a competent developer can act on it. If you then want the work done, that is a separate conversation: your own team can do it, you can hire a developer through us to work through the list, or we can scope the remediation as its own piece of fixed-scope work.
Can you audit a codebase that is still being actively developed?
Yes, and most of them are. We take a commit reference at the start and audit that, so the findings refer to a fixed point rather than a moving target, and we note anything we know is already in flight. Active development actually helps: a team that is still shipping can tell us which parts of the code they are afraid of, and that steer is usually accurate.
Will you sign an NDA, and who owns the report?
Yes to the NDA, before anyone looks at a line of code, and we are happy to work under yours rather than ours. The report is yours: you commissioned it, you paid for it, and you can share it with an investor, an acquirer or your board without asking us. We keep nothing beyond what we need for our own records, and we do not reuse client code as material for anything. The detail is on our contracts and IP page.
Find Out What You Are Actually Holding
Send us the repository size, the stack and the decision the report needs to support. We come back with a fixed price and a scope before anyone reads a line.