A technical due diligence checklist is the structured set of items an acquirer works through when examining a target's product, codebase, infrastructure, and engineering team before close. As of August 2026, having run this exercise from inside eight acquisitions, my view is that nearly every published checklist is a list of documents to request — and documents are the easy part. They describe what someone intends to be true. The checklist below has two columns per stage: what to request, which everyone already has, and what to ask, which is where the actual findings live. The full version is free to copy at the bottom.
What is a technical due diligence checklist?
A technical due diligence checklist is the structured set of items worked through when examining a target's product, codebase, infrastructure, and team before close. Most published versions are inventories of documents. The useful part is the second half: the questions that have to be asked of people, because no document answers them.
Checklists are popular because diligence is frightening and a list feels like control. That is not nothing — a shared list does prevent things being dropped. But completeness against a list and understanding of a business are different achievements, and it is easy to reach the end of one while having none of the other.
Why do document-based checklists miss the important things?
Because documents describe what someone intends to be true. An architecture diagram, a roadmap, and an issue list are all statements of intent. The commit history, the on-call rotation, and what an engineer says when asked what they would fix first describe what is actually true. Only the first set gets gathered by default.
The asymmetry is structural. Documents can be requested in bulk, reviewed by people who were not in the room, and produced on a schedule. Conversations require someone senior enough to interpret the answers, in a room with people who have every incentive to be reassuring. One of those scales and one does not, so the timeline eats the one that does not.
Worth being clear: the request column is not optional. You do need the contracts and the P&L and the security posture. The argument is about which column gets cut when six weeks becomes three.
What are the seven stages of a diligence checklist?
Customer, product, technology, team, economics, risk, and integration — the same frame as the diligence hub. Each stage has two columns. The order matters because each stage constrains the next.
| Stage | Request | The question that earns its place |
|---|---|---|
| Customer | Revenue by account, renewals, churn | Who inside the customer championed this, and are they still there? |
| Product | Roadmap, issues, releases | What does the team believe the roadmap is, asked separately from leadership? |
| Technology | Diagram, spend, dependencies | Which part of this system does exactly one person understand? |
| Team | Org chart, comp, retention terms | Who is staying for the money, and what is their date? |
| Economics | P&L, unit economics | Which work is a founder currently doing for free? |
| Risk | Compliance, legal, key contracts | What are you most worried about that has not come up in this process? |
| Integration | Tooling, cadence | Name the mechanism by which this product got good, in one sentence. |
Two of those are worth calling out. "Who is staying for the money, and what is their date?" gets asked far too rarely, and the answer is usually known. And the integration question is aimed at your own side, before close — if nobody can name the mechanism, the integration plan is being written blind.
How do you use a diligence checklist in a compressed timeline?
Cut the request column before the ask column. Document review scales with people and can be delegated or parallelised; the conversations cannot. If there is time for only one thing, spend it talking to the engineers who will still be doing the work after close, without their leadership in the room.
That last clause does real work. The same engineer gives a materially different answer to "what would you fix first" depending on who is listening, and neither answer is dishonest. One is the answer they can defend in front of their CTO. The other is the one you needed.
What should you do with the answers?
Sort them into priceable and unpriceable. Technical debt, infrastructure cost, and integration effort all get numbers and go into the model. Undocumented judgment concentrated in one or two people does not, and it is the finding most likely to determine whether the acquisition works.
The failure mode is letting the unpriceable findings stay a feeling. They get described in a meeting as "some key-person risk," everyone nods, and it never reaches the memo because there is no column for it. Write it as a sentence with a name attached and a date: if this person leaves within a year, these three things stop working. That is a claim someone can disagree with, which is what makes it useful.
The checklist
Copy it, fork it, paste it into whatever you actually use. It is deliberately plain Markdown so it survives being pasted into a doc, a ticket, or a wiki.
Download the full checklist — seven stages, both columns, roughly forty questions.
Two rules travel with it. Reserve time for unstructured conversation with the people who will still be doing the work after close — it is the cheapest instrument available and the first thing cut. And write down what you decided to leave alone, and why, because a playbook without stated reasons is a list, and lists get executed by people who were not in the room when the judgment was made.
If you only take one line from this: the request column tells you what the company says it is. The ask column tells you what it will be like to own.