Technical due diligence: what investors and acquirers actually check

We run technical due diligence on companies being acquired and companies raising money, and the most useful thing we can tell you is what the work actually is. It is not an audit, and it is not a code review. It is two weeks of a skeptical senior engineer trying to falsify the deal thesis. Every technical claim that supported the valuation — the platform scales, the team is strong, the product is secure — gets treated as a hypothesis and tested against evidence a stranger can verify.

We have written these reports for buyers, and we have sat beside founders on the receiving end. The pattern is remarkably stable: deals rarely fall apart because the code is bad. Everyone's code is imperfect, and diligence teams price imperfection routinely. Deals fall apart, or get repriced hard, when the story and the evidence disagree. This article covers what a diligence team reads in those two weeks, the red flags that turn a finding into a discount, and the preparation that should start about six months before you need it.

How a diligence team spends its two weeks

A well-run technical diligence has the same shape whether the buyer is a private equity fund, a strategic acquirer, or a Series C lead. NDA first, then least-privilege read-only access — repositories, CI, cloud console, issue tracker — plus a document set and interview slots. The evidence request lands on day one, and it looks something like this:

Evidence request — technical due diligence, day 1

Access:     read-only repos, CI/CD, cloud console, issue tracker (revocable)
Documents:  architecture diagram, ADRs, runbooks, last pen test + remediation
Data:       12 months of cloud invoices, deploy history, incident postmortems
People:     45 minutes each — CTO, tech leads, whoever owns production deploys

Notice the ratio: mostly artifacts, very few meetings. That is deliberate. Interviews tell the team what you believe; artifacts tell them what is true. Commit history, CI logs, and cloud bills are nearly impossible to stage on short notice, which is exactly why they get read first and trusted most.

The output is a written report with a risk register — findings ranked by severity, each priced as a cost to fix or a risk to carry, so the deal team can adjust numbers instead of arguing adjectives. A standard engagement runs two to three weeks from access to report; for a hard deal deadline we compress it to ten working days, but only because the evidence checklist stays fixed. The speed never comes from skipping the reading.

The five checks that decide the report

Ask what diligence covers and you will get a two-hundred-line checklist. Ask what actually changes the outcome and it collapses to five checks.

Architecture honesty

The first substantive task is a diff between the architecture diagram and the running system. Not because anyone expects a perfect match — there never is one — but because the size and direction of the gap is the best available proxy for engineering culture. A team that says "this module is a mess, here is why, here is the containment plan" reads as low risk. A team whose diagram shows services that do not exist reads as a team that may be wrong about other things too.

Buyers do not penalize monoliths, either — that surprises founders every time. A boring monolith the team fully understands is a better asset than a microservice estate nobody can explain. What gets penalized is unacknowledged complexity.

Diligence does not price your code. It prices the gap between your story and your evidence.

Bus factor

Commit history is an organizational X-ray, and diligence teams read it as one. Concentration analysis on the repositories answers a question no org chart can: in one recent assessment, a single engineer had authored 62% of the commits to the core billing service — and had no retention agreement anywhere in the deal. That finding moved real money. The buyer's underlying question is blunt: if two named people resign the week after closing, does the roadmap survive the quarter?

Where knowledge accumulates is a structural decision made long before it becomes a diligence finding — we walked through the mechanics in dedicated teams vs. staff augmentation — and a commit graph dominated by contractors on six-month contracts gets read with exactly that risk in mind.

Security posture, in evidence

Nobody on a diligence team reads your security policy PDF as proof of anything; policies are aspirations with headers. What gets checked is the trail. The last penetration test and, more important, the remediation tickets it produced. Access reviews that actually ran, with offboarding tickets showing that revocation happens within days, not quarters. Dependency update cadence visible in lockfile history. Secrets management that does not involve a shared document. A SOC 2 letter answers one question; the trail answers all the others.

Cost of goods

For a software business, infrastructure spend per unit of revenue is a valuation input, and the first check is whether anyone at the target can even compute it. In a cloud cost audit we ran for a payments platform, fewer than half the AWS resources carried usable tags — finance could see a $212k monthly bill but not which product line owned it. For an acquirer, that is not a cost problem. It is a "the margin model cannot be verified" problem, and it gets priced accordingly. The inverse also holds: a unit cost that is attributable and trending down is one of the most underused positive signals a data room can contain.

Delivery metrics that can be verified

"We ship fast" is a claim; a deploy log is a fact. Deploy frequency and change failure rate come straight out of CI history. Lead time comes from merge-to-production timestamps. Incident honesty comes from postmortems — and a company with zero recorded incidents is not a company with zero incidents, it is a company that does not write things down. Verified mediocre numbers beat unverifiable great ones, every single time.

The red flags that kill deals

Very few findings kill a deal on their own. What kills deals is surprise — the discovery that surfaces in week two of diligence when it should have surfaced in the first management meeting. These are the ones we have watched do real damage:

• A diagram that contradicts the code. The finding itself is usually minor. The credibility damage is not, because it attaches a question mark to every other claim in the data room.
• An irreplaceable engineer with no retention plan. The buyer is acquiring a system that lives in one person's head, and that person has no reason to stay past closing.
• License contamination. A copyleft dependency compiled into the proprietary core — or no dependency inventory at all, which forces the buyer to assume the worst and price it.
• Shared production credentials. Beyond the direct risk, it means the access story cannot be audited, so every departed employee is a hypothetical insider.
• A test suite that does not run. Tests that exist but fail, skipped in CI with an apologetic comment from two years ago, are worse than absent tests — they show the team has learned to live with broken signals.
• The undisclosed incident. A breach or a customer-facing outage the team hoped nobody would ask about. Someone always asks. Former employees answer.

None of these is automatically fatal when disclosed early with a plan attached. All of them are dangerous when discovered late, because late discovery converts a technical issue into a trust issue — and trust is the thing the whole deal is resting on.

How to prepare, starting six months out

Preparation is not staging, and diligence teams can smell staging. Preparation is doing the real work early enough that the evidence has time to accumulate — because the trail, not the snapshot, is what gets read.

Six months out: run the diligence on yourself

Use the same checklist a buyer will. Fix cost attribution first, because tagging discipline takes months before the historical data looks like anything but a cleanup. Start writing architecture decision records if you have none: a six-month ADR trail reads as culture, a two-week one reads as decoration. Build the dependency and license inventory now, while there is still time to replace anything radioactive.

Three months out: fix the bus factor and the access story

Write runbooks for every system that has exactly one expert, and rotate deploy duty so the expertise spreads. Run a genuine access review and close the offboarding gaps it finds. Commission the penetration test now — the valuable artifact is not the report, it is the remediation trail behind it, and real remediation takes a quarter. A pen test dated three weeks before diligence, findings unaddressed, reads worse than no pen test at all.

One month out: write the known-issues list yourself

Assemble the data room, make the diagram match the system, and — the step almost everyone skips — write down your own skeletons, each with a containment plan and a cost estimate. You are choosing to present your weaknesses with context instead of letting a stranger present them without it.

What good looks like from the buyer's side

Having read a lot of data rooms, we can describe the target that prices well, because it is rare: the diagram matches the system, the known-issues list arrives before anyone asks for it, the metrics come with the queries that produced them, and the CTO answers hard questions with evidence instead of fluency. That company does not merely survive diligence. It commands a premium, because certainty is worth money to a buyer and almost no target offers any.

If you are on either side of a deal right now — buying, raising, or six months from either — our IT consulting practice runs technical due diligence as a fixed-scope engagement: two to three weeks from access to a written report with a risk register your board can read. And if you would rather find your own skeletons before anyone else does, the same method works just as well pointed at yourself.