What is technical due diligence?

Technical due diligence is the part of a deal where the buyer checks whether the technology can do what the thesis assumes. Every investment in a software company depends on a technical assumption, even when nobody writes it down. This review writes that assumption down and tests it while it is still possible to change the price, the terms, or the plan.

What does technical due diligence actually check?

Technical due diligence checks five things: whether the code is safe to change, whether the system can handle the growth in the plan, whether the team can keep building it, what security and compliance liabilities come with the company, and how much future work is already owed because of quick solutions chosen in the past. Each of those becomes money, time, or risk in the deal, which is what separates the review from an engineering exercise.

A growth deal assumes the platform scales. A venture deal assumes a small team keeps releasing new software. A buyout assumes the roadmap is real and the software can be run by new owners. Technical due diligence tests those assumptions against the actual code, the actual architecture, and the actual team, rather than the description in the pitch deck.

Reveneau runs technical due diligence for investors and opens every review with the same request: the two or three sentences the return depends on, written down by the deal team before anyone reads a line of code. A messy codebase only matters because it slows delivery of the roadmap being funded. An engineer who is the only person able to run a critical part of the system only matters because that person can leave. Checking every observation against the thesis is what keeps the review useful, and the main guide explains how the five areas connect.

Who commissions it, and who runs it?

The buyer commissions it: a venture fund, a private equity firm, a corporate acquirer, or an angel group. The seller prepares for it, and the founder-side view is covered in the separate preparing for technical due diligence guide. A seller can also commission its own review ahead of a sale, which the sell-side technical due diligence page covers.

Who runs it depends on the deal. Papermark's October 2025 survey of due diligence costs lists three provider types by price: specialised technology firms at $300 to $600 per hour, Big Four technology advisory at $400 to $700 per hour, and in-house or network reviews for lighter checks. A 2016 Hacker News thread titled "Startup Technical Diligence Is a Waste of Time" reached 287 points, and the most useful reply in it came from a reviewer who does the work for private equity funds: when a fund takes 51 percent or more of a company, it needs confidence that the technology will keep working, and later-stage venture reviews focus on operational scalability rather than on specific technology choices. The how to choose a technical due diligence firm page turns that into a set of questions to ask a vendor.

How does it differ from a code audit or a penetration test?

Technical due diligence is a business review that uses technical detail. A code audit grades the code in isolation. A penetration test attacks a running system to find exploitable weaknesses. A data room review reads what the company chose to upload. Each is narrower than diligence, and each can be one part of it.

Review type	Question it answers	Who usually runs it	Output
Technical due diligence	Can this software and team support the deal thesis, and what does the gap cost?	A diligence firm or the investor's technical advisers	A priced, ranked list of risks with deal implications
Code audit	How well written is this code against a standard?	Engineers, often with static analysis tools	A quality report with defects by severity
Penetration test	Can an attacker break into this running system?	A security firm	A list of exploitable weaknesses with proof
Data room review	What has the company disclosed?	Lawyers, accountants, the deal team	Notes on completeness and consistency
SOC 2 or ISO 27001 audit	Do the company's controls meet a published standard?	An accredited auditor	A certificate or attestation report

The data room point matters more than it looks. 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, and unit economics) and no technical category at all. The engineering material, which the engineering artifacts for the data room page lists, has to be requested separately.

What does the review look like in practice?

The review follows a set order of steps, and two firms that publish their own process describe the same order. madewithlove, in its May 2024 guide, runs five phases: preparation and information gathering, a two-hour baseline interview with the CTO, a detailed reading of the codebase, follow-up interviews across the team, and a report. It states that it aims to finish within two weeks with up to eight interviews. MEV describes three components: auditing the current state, defining the desired one, and assessing the gap between the two, and states that its core audit runs two to four weeks depending on system size, complexity and how quickly access is granted.

Step	What happens	What the reviewer needs from the target
1. Thesis questions	The deal team writes the assumptions the return depends on	Nothing yet
2. Request list	The reviewer sends the questionnaire and artifact list	A named engineering contact
3. Baseline interview	A long conversation with the technical lead about the system's history	Two hours with the CTO or equivalent
4. Artifact and code review	Reading the diagram, the incident log, the release history, the dependencies, the code	Read access to the repository and the data room
5. Verification	Watching the tests run, having the engineers explain the architecture live, reading a real postmortem	A working session with the engineers
6. Report	Findings priced and ranked, verified separated from reported	Nothing; the reviewer delivers

The how to run technical due diligence page explains each step in detail, the questionnaire is the request list for step 2, and the report structure and template page shows step 6.

Why is the output a price instead of a verdict?

The output is a price because most technical problems are fixable with time and money, and the deal team needs the number rather than a grade. A weak service can be rewritten. A missing test suite can be built. A security gap can be closed. Each has a cost and a timeline, and the job of diligence is to produce that list.

Pricing changes how every finding is read. Instead of "is this good or bad", the question becomes "what does it cost to get this to where the thesis needs it, and is that cost in the price". A codebase that needs six months of cleanup is a cost to raise in the price negotiation. Only a few findings, such as a team that hides problems or a single person who is the only one who understands the core system, move a deal from "price the fix" to "reconsider". The warning signs page collects those.

Real software has old problems and past repairs. A review that fails a company for having them measures the wrong thing. The review also reduces the chance of a surprise after close without removing it, so the honest goal is fewer unpriced risks.

When do you need it, and how deep should it go?

You need technical due diligence any time the technology is a meaningful part of what you are buying, which for a software company is almost always. The depth depends on the size of the deal, and the scope by stage page sets it out in full. In short: a pre-seed or seed check takes a day and looks for whether a product exists and who can maintain it; a Series A or B review takes one to two weeks and tests whether the platform and team can support the next round's plan; a growth or buyout review takes two to four weeks and verifies rather than asks.

The case for doing it at all, even for small investments, comes from the largest published study of angel returns. Wiltbank and Boeker's November 2007 study of 539 angel investors and 1,137 exits found the median diligence effort was twenty hours, that investors above that median saw an overall multiple of 5.9X against 1.1X below it, and that 65 percent of exits with below-median diligence returned less than the money invested against 45 percent above it. The study measured diligence as a whole rather than technical diligence alone, and hours measure care indirectly and do not cause returns, but the result supports the same view this guide takes. The angel investor technical due diligence guide covers what a one-hour and a one-day check can find.

What does it cost, and how long does it take?

Using vendor-stated figures only: MEV prices its own reviews at $5,000 to $30,000 quoted upfront and takes two to four weeks. Papermark's 2025 survey lists specialised firms at $35,000 to $95,000 and Big Four technology advisory at $50,000 to $150,000, and prices the technical review inside a $12 million enterprise value SaaS deal at $22,000 in its worked example. madewithlove aims for two weeks. The what technical due diligence costs page breaks the range down by stage and provider, and if you want the review run rather than priced, our work with VC and private equity firms is where to start.