How to run technical due diligence

Running technical due diligence well is mostly about focus. You have a deal timeline rather than a research budget, so the skill is spending limited time on the few things that decide whether the technology can support the thesis. A review that tries to inspect everything runs out of time before it finds the risks that matter. A review scoped to the thesis finds them fast. The main guide presents every part of the review as answering a business question; this page is the working plan.

Where does the review start?

It starts with the thesis, written down as technical questions, before anyone looks at code. A growth deal depends on whether the platform scales, so architecture comes first. A venture deal depends on whether a small team keeps releasing new software, so the team comes first. A regulated-industry deal depends on compliance, so security comes first. Scoping like this is the decision with the largest effect on the review: get it right and the hours go where the risk is, get it wrong and you produce a thorough report about the wrong things.

The depth then follows the stage. The scope by stage page sets it out in full; the short version is below.

Stage	What the review is for	Depth	Typical length
Pre-seed and seed	Does a product exist, who can maintain it, does anything block the next round?	A conversation and a look at the repository	Hours to a day
Series A and B	Can the platform and team support the next plan?	Interviews, artifact review, selective verification	One to two weeks
Growth and buyout	Verify rather than ask; price everything the thesis depends on	Full review with code access and verification in every area	Two to four weeks

Reveneau scopes every review to a fixed list of thesis questions and quotes it upfront, because a fixed set of questions is what lets a small team with AI doing most of the reading finish within the deal's time limit, and that saving is what lets the review be priced as a fixed fee. MEV, which publishes its own pricing, describes the same approach as three components: auditing the current state, defining the desired one, and assessing the gap between the two.

What should you request before the first call?

Request the engineering artifacts, because the standard data room does not contain them. Andreessen Horowitz's August 2022 guide to data rooms, written for founders, lists five things to include (pitch deck, cap table, historical profit and loss and cash spending, usage data, unit economics) and no technical category at all. So the questionnaire goes to the target on day one, and the engineering artifacts for the data room page describes what each item should look like when it arrives.

The minimum request: read access to the repository, a current architecture diagram, the release history and the five DORA delivery numbers for twelve months, three recent postmortems, the access model, the dependency and licence inventory with its date, the latest compliance report with its date, twelve months of cloud bills, an org chart with tenure, and the team's own list of its worst technical debt. Matt Van Itallie's October 2022 TechCrunch checklist, written to help founders prepare, asks for the same things from the other side, including twelve months of engineering project data split between new features and maintenance. A founder who has read it will have most of the list ready; the founder-side preparing for technical due diligence guide covers the rest.

How do you get real access?

Ask for time with the engineers rather than only the executives, and make the request early. The most common reason diligence is incomplete is accepting the target's presentation. Every company describes its own technology in the best possible way. The people who write the code will tell you, often without meaning to, where the real problems are, because they work with those problems every day.

madewithlove's published process shows what real access looks like: a two-hour baseline interview with the CTO or senior leadership, a detailed reading of the codebase, and follow-up interviews across the team, up to eight in total, inside two weeks. Ask for the same structure. A target that will not give you access to its engineers is itself a signal worth noting, and one the warning signs page covers. When you do get access, you are reading how people think as much as what they claim, which is the same judgment as choosing an external development team.

What do you verify, and how?

Verify the claims the thesis depends on, and label everything else as reported. A claim you confirmed by watching the tests run is far more reliable than a claim from a slide. You cannot verify everything in two weeks, so the list below is the order of priority.

1. Watch the test suite run, on your schedule, from a clean checkout. A suite that passes in front of you is evidence. One that needs "a few environment fixes" is a finding. If the codebase was generated with AI, watch the evaluation suite too; the eval-driven development guide explains what one should contain.
2. Read three real postmortems. Google's SRE book defines a postmortem as a written record of an incident, its impact, the actions taken, the root causes and the follow-up actions. Check the follow-ups were completed.
3. Have an engineer explain the architecture live and compare it with the diagram. The difference between the two is a finding.
4. Read the access list directly from the access system. Count who can reach production and customer data today.
5. Rebuild cost per customer directly from the bill. If the bill and the model disagree, the SaaS metrics versus engineering reality page covers what to do next.
6. Check the commit history for the core service to see how many people have changed it in the last quarter. That is the bus factor, measured rather than asked.

The technical due diligence checklist lists every question with its artifact and its verification method.

How long does it take, and what does it cost?

Two to four weeks, using vendor-stated figures, and the price depends on who runs it. All of the numbers below are stated by the vendors about their own services or their own survey of the market.

Source	Duration	Cost	Notes
MEV, updated August 2026	Two to four weeks	$5,000 to $30,000	Its own reviews, quoted upfront, depending on size and complexity
madewithlove, May 2024	Two weeks	Not stated	Up to eight interviews, a deep code review, a report
Papermark survey, October 2025: specialised firms	Not stated	$35,000 to $95,000	$300 to $600 per hour
Papermark survey, October 2025: Big Four technology advisory	Not stated	$50,000 to $150,000	$400 to $700 per hour
Papermark worked example, October 2025	Not stated	$22,000	Technical review inside a $12 million enterprise value SaaS deal

The largest published study of diligence effort, Wiltbank and Boeker's 2007 analysis of 539 angel investors and 1,137 exits, found a median of twenty hours of diligence per investment and a mean of sixty, and reported that investors above the median saw an overall multiple of 5.9X against 1.1X below it. That study covered diligence as a whole and hours measure care indirectly and do not cause returns, but it is the reason this guide treats time spent as an investment rather than a cost. The what technical due diligence costs page breaks the figures down by stage and provider.

What does the deliverable look like?

A short, clear, priced list of risks sorted by how much they matter to the thesis and how much they cost to fix, with each finding marked verified or reported. Each entry says what the finding is, how confident you are, what it costs in time and money, and what it means for the deal.

The deal team has to decide in the days it has, so give it the three things that change a decision before the thirty that do not. Start with findings that affect the price or the terms. Put the routine repairs in a list for the first hundred days. Mark the rare findings that suggest reconsidering the deal. The way you report risk should follow the same idea as how we measure engineers by outcomes rather than output: report what changes the decision, even when it is hard to count. The report structure and template page shows the full layout, section by section.

Who should run it?

It depends on the deal size and how central the technology is to the thesis.

Option	Fits when	Watch for
Your own technical network	Seed and small Series A checks	Hours are limited and unpaid; the review is not thorough
A fractional or advisory CTO	Series A and B, where judgment matters more than coverage	One person cannot verify every area in two weeks
A specialist diligence firm	Growth, buyout, and any deal where the platform is the asset	Ask how they verify, and whether AI does the reading so the price stays fixed
Big Four technology advisory	Large acquisitions with a wider financial and legal workstream	Papermark lists it as the highest hourly price range

The how to choose a technical due diligence firm page gives the questions to ask a vendor, and fractional CTO versus software development agency covers the middle row. We run this work for investors, both as a standalone review before close and as the team that helps a portfolio company fix what the review found, which we describe in technical due diligence for VC portfolio companies and across our work with VC and private equity firms.

What happens after the report?

The report becomes the first draft of the technology plan for year one. The routine repairs are the first hundred days. The material findings are the first-year budget. The structural findings are in the terms. The turning the diligence report into the first-year plan page in the after-the-deal guide covers that handover, and the warning signs page covers what to do when a finding cannot be priced at all.