Technical due diligence: what to actually check

A technical due diligence checklist should produce a document people actually act on, and most do not: a list of code-quality observations, a dependency report, and a conclusion that the codebase is "generally reasonable with some technical debt".

That tells you nothing, because every codebase matches that description. The useful question is narrower: what will it cost to do the thing you are buying this in order to do?

Judge changeability, not beauty

Elegant code that nobody can deploy safely is worth less than plain code that ships twice a day. So measure the system's capacity for change:

• How often do they deploy? Daily is healthy. Monthly means every release is a large, risky batch.
• How long from merge to production? Hours is good. Weeks indicates a manual gauntlet somewhere.
• What proportion of releases cause a problem? If nobody can answer, that itself is the finding.
• How long to recover? Ask about the last outage specifically, not in general.

A team that can answer these four questions with real numbers is a team with control of its system, almost regardless of what the code looks like.

Bus factor is the usual hidden risk

Ask, of each significant subsystem: if this person left tomorrow, what happens?

The answer is frequently uncomfortable, and it rarely appears in a data room. Key-person concentration is the risk most likely to materially change the value of a deal and least likely to be volunteered.

Concrete probes:

• Who was the last person to touch the payment code? Has anyone else?
• Can a new engineer set up the project from the README alone? Try it.
• When someone is on holiday, what waits for them?
• Is there any documentation written for a reader who was not present?

The checklist

Codebase

• Tests exist on business-critical paths, and they run in CI
• CI is green, and has been for more than a week
• No secrets in version control, current or historical
• Dependencies within a supportable range; no unmaintained core libraries
• Licences compatible with your intended use — check transitively

Architecture

• Someone can draw it on a whiteboard in five minutes
• Failure modes have been thought about; there is a plan for the database going away
• The data model matches the business; heavy workaround layers indicate an early wrong turn
• Scaling constraints are known rather than theoretical

Security and data

• Authentication and authorisation are centralised, not scattered
• Personal data is inventoried and its retention is defined
• Someone owns dependency and security updates
• Access to production is limited, logged and revocable

Delivery

• Deploys are automated and reversible
• There is a staging environment resembling production
• Monitoring and alerting exist, and someone is on call
• Incidents produce written follow-ups

Team

• No subsystem is understood by exactly one person
• Code review is real, not ceremonial
• Onboarding takes days rather than months
• The engineers can explain the product's business model

What AI changed

Two adjustments are now worth making explicitly.

Volume is no longer evidence of capability. A large, recently written codebase used to imply a substantial team working for a long time. It no longer does. Look for whether verification scaled with generation: is there review history, are there tests, can anyone explain the critical paths?

Dependency provenance deserves a real look. A USENIX Security study found code-generating models importing non-existent packages at rates between 5.2% and 21.7% depending on the model, and attackers have responded by registering the invented names. Check that dependencies were vetted rather than accepted, that lockfiles are committed, and that the build would fail rather than silently resolve if a package disappeared.

A scoring approach that survives a real deal

A checklist of yes-or-no items is useful for coverage and useless for prioritisation — every real target fails some items, and the question that matters is which failures are disqualifying and which are just normal wear. A simple weighting fixes this.

Score each area on a rough scale — critical gap, manageable gap, or clean — rather than treating every checklist item as pass-fail:

A target with one critical gap and several manageable ones is usually still a good deal, priced accordingly, with the critical gap named explicitly as a condition or a post-close priority. A target with critical gaps across three or more areas is a different conversation entirely — not necessarily a dead deal, but one where the technical remediation cost needs to be modelled seriously before a price is agreed, not discovered afterward.

A worked example: what a real two-day review finds

Concretely, so the checklist above has a shape attached to it — a composite of patterns we see repeatedly, not any single real engagement.

Day one, codebase and architecture. The repository clones and, after forty minutes of chasing missing environment variables nobody had documented, runs locally. Test coverage exists but only on about a third of the codebase, concentrated on the parts built in the last year — the older core, including the billing logic, has none. The architecture is a monolith with two services split out more recently, and the split looks like it followed team boundaries rather than a deliberate design, which is a normal and not disqualifying pattern, but worth naming as a factor in future hiring and team structure.

Day one, security and data. Authentication is centralised through a single well-known provider — good. Personal data retention has never been formally defined; nobody could say how long inactive user data is kept, which is a manageable but real gap given the target operates in a jurisdiction with data retention obligations. No secrets found in the current repository, but a scan of git history from three years ago turns up an old API key — rotated since, but the practice of scanning history rather than just the current tree is what surfaces this.

Day two, delivery and team. Deploys run through CI and happen most days — healthy. The team could not immediately produce a change failure rate, but after being asked, pulled one together from their incident channel: roughly one problem per fifteen deploys, which is reasonable. The engineer conversations, held without the CTO present, surface that one person — who is leaving in two months for unrelated reasons — is the only one who fully understands the payments integration. This is the finding that actually changes the deal: not a defect in the code, but a departure risk that was not in the data room and that materially affects the near-term cost of owning this system.

The report from a review like this does not conclude "the code is fine" or "the code is bad." It says: the payments bus-factor risk needs to be addressed before or immediately after close, ideally through a paid handover period with the departing engineer; the billing code's lack of test coverage adds real risk to any change in that area for the first few months; and everything else is a normal, priced-in level of technical debt that does not change the fundamental case for the deal.

Talk to the engineers alone

Half an hour with two or three engineers, without their manager in the room, will tell you more than the data room.

Ask what they would fix if given a month. Ask what worries them. Ask what they were told not to mention. Engineers are, as a group, remarkably straightforward about the state of their systems when nobody is performing.

A code audit before acquisition is not the same as ongoing engineering review

Worth distinguishing explicitly, because the two get conflated and the conflation causes bad scoping. A code audit before acquisition is a time-boxed, decision-focused exercise: its job is to inform a go/no-go and a price, within days, not to produce a comprehensive engineering roadmap. Engineering due diligence more broadly can extend beyond code into process, team structure and roadmap feasibility — closer to what an operating partner might do post-close than what a deal team does pre-signing.

Confusing the two produces either an acquisition review that runs for three weeks trying to be comprehensive, missing the deal deadline in the process, or a rushed two-hour code skim that calls itself due diligence and catches almost nothing that matters. The checklist and scoring approach above is scoped deliberately for the first kind — fast, decision-focused, proportionate to a deal timeline — and explicitly not a substitute for the deeper engineering assessment a new owner would want to run in the first ninety days post-close, once there is time and access that a pre-signing process rarely has.

Software due diligence as a broader category also covers licensing and intellectual property questions that sit adjacent to the technical checklist above but are worth a separate mention, because they are easy to miss during a purely technical review. Confirm that the codebase's open-source dependencies carry licences compatible with your intended use — a copyleft licence buried three dependencies deep can constrain what you are legally able to do with the code even if the code itself is excellent. This is a five-minute automated scan, not a manual review, and there is no excuse for skipping it.

Writing it up

A useful report says three things:

1. What it would cost to do the intended thing — in engineer-months, with the assumptions stated
2. What must be fixed before that starts — the short, specific list
3. What risk remains — key people, unsupported dependencies, unresolved compliance

Not a catalogue of imperfections. Every codebase has those, and listing them obscures the three things that actually matter.

Where these findings usually lead

The most common outcome of a diligence review that surfaces real findings is not walking away — it is adjusting the plan. A bus-factor risk becomes a condition that the key engineer stays on for a defined handover period. A thin test suite becomes a budgeted first-quarter priority rather than a surprise discovered mid-integration. If the review points toward genuine architectural problems rather than manageable gaps, the choice between fixing incrementally and starting over is covered in rewrite versus refactor — most of the findings a diligence process surfaces resolve through incremental work, but knowing when they do not is worth having a framework for going in.

Where the findings suggest the target needs meaningful engineering investment post-close, technical debt explained for founders covers how to size and prioritise that work without either ignoring it or treating it as an emergency that halts everything else.

The review that pays for itself

A two-to-five-day technical review is a small fraction of most deal sizes, and the findings it surfaces — a bus-factor risk, a dependency gap, an undocumented compliance hole — are precisely the kind of thing that is cheap to discover before signing and expensive to discover after. Treating this checklist as a standard, non-negotiable part of any acquisition or significant investment process, rather than an optional extra reserved for deals that already feel uncertain, is the practice that consistently pays for itself over a portfolio of deals even when any single review finds nothing alarming.

In one sentence

Judge a codebase by how safely it can change and how many people understand it, not by how it reads on a first skim.

A practical next step

Before your next acquisition conversation reaches serious terms, send the target company this checklist and ask them to self-assess against it honestly, before any external reviewer is engaged. How they respond to that request — thoroughly and specifically, or vaguely and defensively — is itself useful diligence, often before a single line of code has been read.

What separates a good review from a routine one

The difference between a diligence review that changes the outcome of a deal and one that merely confirms what everyone already suspected usually comes down to how willing the reviewer is to say something uncomfortable clearly, rather than hedging it into vagueness. A review that lists forty minor observations without a clear priority is far less useful than one that says plainly: this one thing is the reason to reconsider the price, and everything else is normal.

One more thing worth saying

The goal of this checklist is not to find a perfect codebase — none exists. It is to know precisely what you are buying, so the price and the plan both reflect reality.