Technical Due Diligence: What Acquirers Actually Check

TL;DR: Technical due diligence is not a code review. It is a risk-pricing exercise: can this product keep shipping if we buy it, and what will keeping it alive actually cost? The diligence team will look past your architecture diagram and into your git history, your ticket flow, and your org chart. The findings that move valuations are almost never "the code is ugly." They are concentration, debt, and contradiction. All three are measurable in advance, which means all three are fixable in advance. Here is what gets checked, what actually moves the number, and how to walk into the data room having already read your own report.

What technical due diligence is, and when it happens

Technical due diligence (tech DD) is the engineering audit that runs alongside financial and legal diligence in a fundraise, acquisition, or major partnership. A diligence team - sometimes the acquirer's engineers, often a specialist firm - gets days to weeks with your repositories, your infrastructure, your documentation, and your people, and produces a report that feeds directly into price and deal terms.

The buyer's question is not "is this good code?" It is "what am I actually buying, and what liabilities come with it?" Software is bought as a going concern. The asset is the ability to keep changing the product. That reframing explains everything on the checklist below, and it is why the evidence that matters most is longitudinal. Your repository is a diary you have been keeping for years, and the honest economics of your engineering org are written in it whether you have read them or not.

The technical due diligence checklist: what acquirers actually check

Every diligence firm has its own template, but the substance clusters into five areas:

• Architecture and code health. Structure, dependencies, test presence, and the debt picture. Not cosmetics - trajectory. A diligence team wants to know how much of future engineering spend is already committed to servicing the past. For calibration on why they care: McKinsey's CIO survey found respondents reporting that 10 to 20 percent of the technology budget dedicated to new products gets diverted to resolving tech-debt issues, with accumulated debt estimated at 20 to 40 percent of the value of their entire technology estate (McKinsey). Numbers like that are precisely why the debt section of the report exists, and why you should have priced your own technical debt first.
• Knowledge concentration and key-person risk. Who actually understands each system? The research is blunt: an analysis of 133 popular GitHub systems found roughly 65 percent had a truck factor of two or fewer, and 34 percent sat at a truck factor of one (Avelino et al., 2016). A diligence team will build some version of this map from your commit history (how bus factor gets calculated is not a secret), and every subsystem that one person owns becomes a line in the risk register and, often, a name in a retention clause. If you want to know what they will find, measure your key-person risk before they do.
• Delivery capability. Does change flow through review, CI, and deployment in a controlled, repeatable way, in the data rather than the wiki? Claimed process that the git history contradicts (unreviewed merges, release branches that live for months, deploys nobody can reconstruct) is worse than a modest process honestly described. This is where review coverage and basic delivery metrics get pulled, because they are cheap for a diligence team to compute and hard to stage-manage.
• Security, IP, and licensing hygiene. Dependency licenses, secrets handling, access control, and clean IP assignment. Mostly binary findings: fine until one is not.
• The engineering P&L. How engineering spend maps to what was built, including whether capitalized development stands on defensible ground. If development costs sit on the balance sheet, expect the criteria of IAS 38 (or the local equivalent) to come up, and expect the support for capitalizing development work to be tested against actual engineering records rather than a spreadsheet from April.

The findings that actually move valuations

Diligence reports are long; the deal conversation is short. Three classes of finding dominate it:

1. The one-person system. A revenue-critical component with a single meaningful contributor converts directly into deal mechanics: retention bonuses, escrow, longer earn-outs, or a price adjustment. The acquirer is not being dramatic: they have read the same research you just did, and they know what happens when that senior engineer quits.
2. Debt that eats the roadmap. Not the existence of debt (everyone has it; in the Stack Overflow 2024 survey technical debt was the top frustration, named by 63 percent of professional developers, per Stack Overflow). What moves the number is unpriced debt: leadership that cannot say what share of engineering time it consumes, in which systems, trending which way. Vague debt is priced pessimistically, because it is priced by the party with the least incentive to be generous.
3. Contradiction. The pitch says "rigorous review culture"; the history shows self-merged hotfixes every Friday. The pitch says "the team scales"; the ownership map shows a single point of failure under every load-bearing wall. Any one contradiction discounts every other claim in the room - the same way an invented statistic poisons a deck.

Notice what is not on this list: tabs versus spaces, framework choices, the monolith. Diligence teams have seen a thousand codebases, and yours will not shock them. What they price is risk.

How to prepare for technical due diligence

The preparation strategy is one sentence: run the diligence on yourself, early, and act on it. In practice:

• Build the ownership map now. Compute the bus factor per system from your own history. Where it is one, either spread the knowledge or document the risk and its mitigation plan. "We know, here's the plan, here's the progress" is a fundamentally different finding than "they hadn't noticed."
• Price the debt with a method. Time share × loaded cost, receipts attached, the same discipline as any honest debt pricing. A team that presents its debt as a managed number with a trend line has flipped the finding from liability to evidence of competence.
• Close the say/do gaps. Whatever process you claim, verify the data agrees: review coverage, CI on the main path, reproducible deploys. Fix the practice or fix the claim; either is respectable, and the gap is not.
• Assemble the receipts before they are demanded. Architecture notes, dependency and license inventory, access model, incident history, and the engineering-time evidence behind any capitalized development. Diligence teams read speed-of-answer as a signal in itself: an org that can produce its receipts in a day is an org that knew where they were.

The door

You do not need a term sheet to justify any of this. Everything on the diligence checklist - concentration, debt, delivery honesty, clean receipts - is exactly what you would want fixed anyway, deal or no deal; the acquirer's checklist is just a well-motivated audit of things that were already costing you money. So run it this quarter, on yourself, while every finding is still cheap to fix and nobody is holding a discount over the table. The best position to negotiate from is having already read the report - because you wrote it.