An independent read before you commit further
Codebase Assessment
An inherited system, a departed contractor's code, or a target company before you sign are different situations that all need the same thing: a structured, independent read before you commit further. This is that read on its own terms, not bundled inside a larger scoping conversation. The output is a system map and a risk register your team can act on immediately.
What a codebase assessment produces
The system map, the risk register and the decision brief, walked through by the engineers who write them.
90 secSample frame · video pending01Three reasons, one audit
Name why you need an independent read.
An investor's question, a change of ownership, and a persistent worry about quality are different triggers for the same discipline. Each one deserves the system read honestly, on its own evidence, before anyone commits to a decision. What changes is which findings get emphasised, not what gets examined.
Why do you need this audit right now?The reason behind the audit changes what gets emphasised. Pick yours and the recommendation adjusts.
Pre-transaction codebase assessment
A transaction deadline means the audit has to be fast, defensible and written for people who are not engineers, without softening what it actually found.
A one-page risk summary within the first week, ahead of the full register, so the deadline is never the excuse for skipping diligence.
- Architecture and structureIs the system built to support what happens next, or just what already happened?A structural read against your actual roadmap, not a generic best-practice checklist.
- Security postureWhere would an attacker actually get in?Targeted testing of authentication, access control and the paths handling sensitive data.
- Decision readinessIs there enough here to support the decision waiting on it?A one-page brief stating the recommendation plainly enough to act on immediately.
None of the three reasons match, or there is more than one at once? Describe your situation instead
02Two weeks, start to finish
Structured enough to defend in a board meeting.
The pace is set by the size of the estate rather than the size of the worry. A single service is read in two weeks; a sprawling one is split into a scoped first pass and a deeper follow-up. Either way, the method stays the same and nothing about it is improvised.
Access and scope confirmation
A short call to confirm what triggered the audit and what decision it needs to support, then read-only access to the repository, tickets and whatever documentation already exists.
First moveArchitecture and dependency review
Structure, dependencies, licences and security posture are examined against how the system is actually used in production, not against a generic checklist that ignores your traffic.
The read itselfFindings ranked and priced
Every finding is ranked by business consequence and, where relevant, priced to fix, so the register reads as a decision tool rather than a list of complaints.
The verdictHandover and walkthrough
The system map and risk register are handed over and explained directly to your team, usable whether the next step is a hire, a rebuild, or nothing at all.
Yours to keep
03The audit record
Four documents built for a real decision.
This is not a slide summarising confidence back to you. It is a working record: what the system actually contains, what is genuinely risky, what it would cost to fix, and a plain recommendation stated for whoever has to sign off.
System map
Architecture, dependencies, integration points and any technical decision that would be expensive to reverse later, documented plainly enough for a new engineer to read cold.
Risk register
Every material finding ranked by business consequence, from security exposure through to the technical debt that quietly slows every future release.
Cost-to-fix estimate
A priced view of what closing the highest-priority findings would take in time and budget, so remediation can be planned rather than guessed at.
Decision brief
A short, board-ready page stating the recommendation plainly, with the supporting evidence attached for whoever has to sign off on what happens next.
04Evidence and proof
Audits that changed what happened next.
Nothing below ships without the client's written sign-off, so treat every example as a preview of the standard rather than a finished case. Ask us directly for whatever detail matters most before deciding anything.
Explore case studiesAn acquisition audit that reset the purchase price by a third.
Pillar Learning's board was ready to close on an acquisition target until the codebase assessment found a licensing exposure and a dependency nobody had patched in three years. The finding did not kill the deal; it changed the number attached to it.
- Time to findings
- Nine days
- Purchase price adjustment
- Material
The register gave our board a reason to negotiate instead of just hoping for the best.
Sample · pending client approval
05When a standalone audit is not the right shape
Three situations where this audit is not the answer.
Not every audit question needs a standalone engagement: some belong inside a broader scoping conversation, and some point straight at a specific rescue rather than a general read. We would rather route you correctly than run an audit that answers the wrong question.
- Project Scoping
You have not committed to a build yet
If the system in question does not exist yet and you are weighing what to commission, project scoping settles the shape of the work before any code is written.
- AI-Built Rescue
The trigger is specifically AI-generated code
If the concern is narrower than a general audit, AI-generated logic behaving strangely in a live product, the dedicated rescue path goes deeper into that specific failure mode.
- Legacy Modernisation
The finding is already known: rebuild in stages
If your team has already concluded the system needs a phased rebuild rather than a diagnosis, go straight to the practice that scopes modernisation work directly.
06Straight answers
Questions asked before an audit is commissioned.
01What triggers a codebase assessment?
Most often an investment decision, an acquisition, or the moment ownership of a system changes hands. Sometimes there is no single trigger at all, just an accumulated, ongoing unease about quality that nobody has measured properly.
02Do you need our AI tool history for this audit?
Only when AI-generated sections are part of the estate, and even then it is optional context rather than a requirement. The code itself is examined on its own behaviour regardless of origin.
03How is this different from technical due diligence?
The two exercises share methods but not audiences. An acquirer's diligence process folds the technical read into a broader financial and legal picture aimed at a purchase decision. Here, the read stands alone, aimed at whoever now has to run, fix, or replace the system regardless of who owns the company.
04What if the audit finds nothing seriously wrong?
That is a genuinely useful result, not a wasted fee. A clean system map lets you make the investment, acquisition or ownership decision with confidence instead of hope, which is exactly what the audit was for.
05How much of the codebase do you actually review?
Enough to state a defensible position on architecture, security and technical debt, not necessarily every line. Sampling is targeted at the highest-risk modules first, and we say plainly which parts were read closely versus reviewed at a higher level.
06Will you tell us if the system should just be replaced?
Yes, and we would rather say that early than pad a repair plan nobody should fund. The risk register states plainly when the honest recommendation is a phased rebuild instead.
07How long does a codebase assessment take?
Typically two weeks for a single system of normal size, split into a first pass and a deeper follow-up for anything larger or unusually tangled. A shorter, scoped pass is available when a decision deadline is fixed.