Technical due diligence is the examination of a target company's product, codebase, architecture, and engineering team before an acquisition closes. As of August 2026, after fifteen years building platform software in regulated healthcare and leading product through eight acquisitions from inside the organization rather than the deal team, I've come to think diligence rarely fails for lack of data. It fails on the questions asked. The deal asks whether the asset is as described, and answers that well. The operator asks what this will be like to own on a Tuesday eighteen months from now, and almost nobody has time for that question during the window when it could still change the price.
What is technical due diligence?
Technical due diligence is the examination of a target company's product, codebase, architecture, and engineering team before an acquisition closes. It exists to price risk the financial model cannot see: what the system actually costs to run, what it will cost to integrate, and whether the people who understand it will still be there in a year.
Technology due diligence and software due diligence describe the same exercise with different emphases — one leans toward architecture and infrastructure, the other toward the codebase itself. In practice the boundary matters less than who is asking. A firm running the process for a lender wants a defensible report. An operator who will inherit the system wants to know what is going to hurt.
Both are legitimate. They produce different documents.
Why does technical due diligence miss what matters?
Because it usually answers the deal's questions rather than the operator's. The deal asks whether the asset is as described. The operator asks what this will be like to own on a Tuesday in eighteen months. Both are legitimate; only one of them predicts what happens after close, and the window is almost always spent on the first.
The structural reason is that diligence is scoped by people who will not operate the result. That is not a criticism — it is how the incentive works. The deal team is measured on getting to a defensible close. The operators arrive afterward, inherit whatever was true, and have no mechanism to send questions backward in time.
So the artifacts requested are the ones that are easy to request. An architecture diagram. A roadmap. A list of open issues. Each of those is a description of what someone intends to be true. The commit history, the on-call rotation, and what an engineer says when you ask what they'd fix first are descriptions of what is true. Only one set gets gathered by default.
What are the seven stages of product and technology diligence?
Customer, product, technology, team, economics, risk, and integration. The order matters, because each stage constrains the next. A technology finding means something different depending on what the customer stage revealed, and an integration plan built before the team stage is a plan resting on an assumption about who will still be there to execute it.
| Stage | The question | What it looks like when skipped |
|---|---|---|
| Customer | Who actually uses this, and will they stay? | The logo list survives; the champions who renewed it leave |
| Product | What has been promised, to whom? | Commitments surface after close, priced at zero |
| Technology | What will this cost to run and to change? | Integration estimates built on the diagram, not the system |
| Team | Who understands this, and what happens to them at close? | Retention holds bodies; the knowledge leaves anyway |
| Economics | Which costs are structural, and which are unpaid founder labour? | Margin evaporates on contact with a real org chart |
| Risk | What is load-bearing that nobody wrote down? | Discovered during the first incident |
| Integration | Consolidate or leave it alone? | A rational decision that quietly damages the thing you bought |
I keep this frame in my head on every one of these now. The moment a diligence workstream cannot say which stage it is answering, it has usually drifted into gathering documents.
What is the difference between the deal's questions and the operator's?
The deal's questions are answerable from documents: what exists, what it earns, what it owes. The operator's questions are answerable only from conversation: what is load-bearing that nobody wrote down, what the team believes the roadmap is, and which departures would actually hurt. Documents are gathered; the other kind has to be asked for.
That distinction is the whole argument of this series. It also explains why diligence quality correlates poorly with diligence volume. A four-hundred-page data room and six weeks of review can leave every operator question untouched, because none of them have a document that answers them.
The practical move is small: in every diligence, reserve time for unstructured conversation with the people who will still be doing the work after close. Not a presentation. A conversation, without their leadership in the room, about what they would fix first and what they are worried about. It is the cheapest instrument available and the first thing cut when the timeline compresses.
When should you walk away from an acquisition?
When the thing being bought turns out to be a person rather than a system, and that person's incentives end at close. Technical debt is priceable. Integration cost is estimable. Undocumented judgment concentrated in one or two people who are about to become wealthy and unmanaged is the risk with no number attached to it.
That is not an argument against acquiring small teams. It is an argument for knowing which one you are doing. Buying a system and buying a capability are different transactions with different failure modes, and the diligence that serves one is close to useless for the other.
The same discipline shows up elsewhere in how I think about building: reduce the uncertainty, establish the evidence, then make the next decision. An acquisition is that loop run once, expensively, with a signature at the end of it.
The rest of this series takes the seven stages one at a time.