A technical due diligence checklist

A checklist does two things under deal pressure. It stops you forgetting an area, and it gives you a consistent way to compare targets. The list below is organised by area, and each item pairs a question with the artifact that proves the answer. Treat it as a set of questions to answer with evidence rather than a form to tick. The main guide explains why the areas belong together, and how to run technical due diligence covers the process around the list.

How should a technical due diligence checklist be organised?

Organise it by area, with a question, an artifact and a verification method for every item. The published checklists agree on the topics even where they name them differently. madewithlove's May 2024 guide assesses five areas: infrastructure, code quality, scalability, team and workflow, and security and compliance. Matt Van Itallie's October 2022 TechCrunch checklist, written from the founder's side, groups its requests into product roadmap, code quality, intellectual property, security, development process, engineering team contributions and DevOps. A 2023 Hacker News thread sharing a 100-question diligence checklist reached 253 points, and its most-upvoted criticism was that the list had no technical section at all.

Reveneau's diligence checklist adds three columns to the usual two: the question, the artifact that answers it, and how the reviewer verified it, because the difference between a claim and a verified claim is the whole value of the review. The questionnaire is the version of this list that goes to the target as a request, and the engineering artifacts for the data room page describes each artifact and what a good one looks like.

What does the checklist ask about code quality?

It asks how fast and safely the team releases a small change, and it asks to see the evidence run.

Question	Artifact to gather	How to verify
What are your five DORA delivery numbers for the last twelve months?	A dashboard or export: change lead time, deployment frequency, failed deployment recovery time, change fail rate, deployment rework rate	Compare with the release log
What share of the code is covered by automated tests?	A coverage report	Watch the suite run, on the reviewer's schedule
How is a change reviewed before it merges?	The pull request history for the last quarter	Look for reviewers who change other people's code
How large is a typical change?	The same history	Google's guidance puts a reasonable change near 100 lines and 1,000 as too large
What happens between merged and live?	The pipeline definition, the release runbook	Ask an engineer to explain each step

The assessing code quality page explains what good answers sound like and what the DORA metrics mean.

What does it ask about architecture and scalability?

It asks the team to explain the system as it is today and to name what breaks first.

Question	Artifact to gather	How to verify
Explain the architecture and where user data lives	A current diagram	A live explanation compared with the diagram
What breaks first as we grow, and at what scale?	The team's own answer, in writing	Check it against the incident history
What are your service level objectives and your error budget?	The objectives, the dashboards	Ask for the last month's numbers
Describe a recent outage	Three recent postmortems	Check the follow-up actions were completed
What does the infrastructure cost, and how does it change with users?	Twelve months of bills, split by product and environment	Rebuild cost per customer from the bill

The assessing architecture and scalability page covers what to listen for, and the cloud cost due diligence page covers the last row in detail.

What does it ask about the engineering team?

It asks who holds the knowledge, how senior the people are, and how they behave when something goes wrong.

Question	Artifact to gather	How to verify
Who are the senior people, and do they work on the core?	An org chart with seniority and tenure	Commit history for the core service
If this one person left tomorrow, what would happen?	The team's answer	Who else has changed the core in the last quarter
Where is the knowledge written down?	Design documents, runbooks, specifications	Read one and check it matches the code
Explain a hard technical decision in plain language	A conversation with the engineers rather than only the executives	Clarity of the explanation
Who has left in the last twelve months, and why?	A leavers list	References where possible
Who reads generated code before it merges, and what checks it?	The review policy, the pipeline	See the checks run

The assessing the engineering team page covers this in detail, since the team is the asset that produces every future version.

What does it ask about security and compliance?

It asks the six basic security questions first, then compares the controls with a published framework.

Question	Artifact to gather	How to verify
Who can reach production and customer data, and how is that controlled?	The access model, the list of accounts with production access	Read it from the access system
Where are secrets stored?	The secrets management setup	Search the repository history for keys
How are systems and dependencies patched?	The patching policy, the dependency inventory and its date	Check against CISA's Known Exploited Vulnerabilities catalogue
Is sensitive data encrypted in storage and in transit?	The data classification and encryption settings	Query a table
What would detect an attack, and when was a restore last tested?	Monitoring alerts, the last restore test date	Ask for the alert that fired most recently
Which standards apply, which do you hold, and when was the last report?	The SOC 2 or equivalent report with its date	Read the report
What security incidents have you had, and what changed?	The incident log and write-ups	Compare the team's account with the record

Map the answers against the OWASP Top 10:2025 (from broken access control at A01 to mishandling of exceptional conditions at A10) and against the six functions of NIST's Cybersecurity Framework 2.0 (Govern, Identify, Protect, Detect, Respond, Recover). The assessing security and compliance page explains why these are liabilities you inherit and how the disclosure deadlines work.

What does it ask about technical debt?

It asks the team to list its own debt and then checks whether releases are slowing.

Question	Artifact to gather	How to verify
Is it getting harder to release changes, and which part of the code is hardest to change?	The team's answer	The DORA lead time trend over twelve months
What would you fix with three months of only debt repair?	The team's list, ideally a debt register	Where the items are: core system or minor features
How much of your time goes to working around problems in the codebase?	The team's estimate	The share of fix and hotfix changes in the history
Is debt repair part of how you plan?	Planning records, roadmap	Look for debt items that were completed

The assessing technical debt page covers how to sort what you find using Fowler's quadrant.

What does it ask about open source, cloud cost and AI-written code?

These three sections are newer and now appear in most reviews.

Open source licences. Morgan Lewis's June 2026 note on open source in M&A diligence lists the questions a buyer's counsel asks: whether the company has a written open source policy, whether staff are trained on licence obligations, whether the company contributes to outside projects, how it tracks the open source it uses, whether it scans the codebase, and how it approves software under copyleft licences such as the GPL. Gather the scan output and the policy. The open source licence due diligence page covers the licence classes and the remediation options.

Cloud cost. Gather twelve months of bills split by product, customer and environment, the name of the person responsible for the bill, and the answer to "what happens to cost if traffic doubles". The cloud cost due diligence page shows how to rebuild gross margin from the bill, and the SaaS metrics versus engineering reality page covers what to do when the bill and the model disagree.

AI-written code. Gather the specifications the code was generated from, the review policy, and the evaluation suite if one exists, and watch it run. Google's October 2024 DORA report associated a 25 percent increase in AI adoption with a 7.2 percent decrease in delivery stability, so the question is what catches the almost-right code. The eval suite as a diligence artifact page covers what a good one looks like, and how to evaluate a vendor's eval suite covers the same question for a supplier.

How do you turn the list into a decision?

Do two things once every area is done.

1. Mark each finding verified or reported. A finding you confirmed yourself, by watching a test suite run or reading an incident record, is more reliable than a claim taken from a slide. A target reluctant to let you verify is itself a finding.
2. Score each finding by cost and time to fix. That turns a long, unsorted list of observations into a priced, ranked list, which is the real output of diligence.

Score	Meaning	Where it goes
Routine	Known repair, weeks, any competent team	First-hundred-days plan
Material	Months of senior effort, or a commercial timeline such as a certification	Price and the first-year plan
Structural	Cannot be sized yet, or points to the team or culture	Terms, or a warning sign

The report structure and template page shows how the scored list is written up, and the scope by stage page says which sections of this checklist apply at seed, at Series A and B, and at growth or buyout.