You closed the deal, or you're about to. The diagrams and the data room told you one story. The code tells the real one. Here's what to assess, in what order, and how to read a system the prior team built without taking their word for it.
Every acquisition arrives with an architecture diagram, a team chart, and a confident narrative. None of them is the system. The system is in the code, the commit history, the tickets, and the few people who remember why each decision was made — and that is exactly where the surprises live: the module two contractors built and left, the dependency with a license you can't ship, the revenue-critical service one person understands.
Evaluating an acquired or inherited codebase means answering, from evidence, the questions that actually decide whether you integrate, invest, retain, or rebuild. The six below are the ones that matter most.
Reconstruct the system as it's actually deployed — services, data flows, coupling, and single points of failure — from the code, not the diagram in the data room. The gap between the two is the first sign of how much you don't yet know.
Commit-history analysis shows which people hold unique expertise over critical modules. A bus factor of one on revenue-critical code is a material risk — and you want to know it before the earn-out ends and that person leaves, not after.
Not "the code is messy." Surface the code that is both complex and frequently changed, and express the cost by business domain in money and time. That's the number that tells you what integration and modernization will actually take.
Latent vulnerabilities, business-logic flaws, and gaps against the standards the system claims to meet — read from the code rather than a compliance questionnaire the prior team filled out. Inherited exposure becomes your exposure on day one.
Inventory every declared and undeclared dependency, and flag copyleft contamination, AGPL exposure, and end-of-life packages. This is how you confirm you actually own — and can legally ship — what you just bought.
Normalize the custom code to person-years and separate genuine IP from open-source and boilerplate. It values the asset, and it tells you whether keeping, rebuilding, or consolidating is the right call.
A technical review is usually a lighter, interview-led look at a system — its stack, team, and obvious risks. A codebase audit reads the source, commit history, and dependencies directly to produce reproducible evidence. For an acquisition, the audit is what holds up to scrutiny, because every finding traces to the code, not to what the team told you.
Same analysis, different moment. Pre-close technical due diligence frames the findings for the deal — what you're buying and what to price in. A post-acquisition or inherited-codebase audit frames the same evidence for the team now running the system — what to integrate, fix, retain, or rebuild, and where the key-person risk sits before anyone walks.
Our read runs two weeks, fixed price, and is read-only — access to repos and history under NDA in an isolated environment, no meetings required with the acquired engineers. They keep shipping while we read. You get a board- or IC-ready picture by week two.
Two weeks. Fixed price. Read-only. One conversation to start — we'll tell you if we can't help.
Get a Read