Technical due diligence: a complete guide for investors

Technical due diligence is the part of a deal where the buyer checks whether the technology can do what the investment thesis assumes. Every investment in a software company depends on a technical assumption, even when nobody writes it down. A growth-equity deal assumes the platform can serve ten times the users. A venture deal assumes a small team can keep releasing new software. A carve-out assumes the software can be separated from its parent company. This review writes that assumption down and tests it while it is still possible to change the price, the terms, or the plan for the first hundred days.

This guide is written for the people who commission the review: partners and associates at venture and private equity funds, corporate development teams, and the founders whose companies are about to be reviewed. It assumes no engineering background. Where a term is needed to search for something or to ask a vendor a question, the term follows the plain explanation. If you want the review run rather than explained, that is what our work with VC and private equity firms is for.

The short version

• Technical due diligence answers one business question: can this company's software, and the people who build it, support what we are paying for, and if not, what does the gap cost.
• It assesses five areas that affect each other: code quality, architecture and scalability, the engineering team, security and compliance, and technical debt.
• The output is a priced, prioritised list of risks, each marked as verified or reported, with the three findings that change the decision at the top.
• Vendor-stated figures put the work at two to four weeks. MEV quotes $5,000 to $30,000 for its own reviews; Papermark's 2025 survey of the market lists specialist firms at $35,000 to $95,000 and Big Four technology advisory at $50,000 to $150,000.
• Most findings are repairs with a cost. A few are structural, and those change the discussion from "price the fix" to "reconsider the terms".
• The review is scoped to the thesis: a growth deal starts with architecture, a venture deal starts with the team, a regulated-industry deal starts with compliance.
• Diligence hours are correlated with returns. In the largest study of angel exits, investors who spent more than the median twenty hours on diligence saw a 5.9X overall multiple against 1.1X for those who spent less.

What technical due diligence is, and what it is for

Technical due diligence is a review with a fixed scope, run before the money is paid, of the software a company sells and the engineering organisation that builds it. It is commissioned by the buyer or investor, run by people who assess software for a living, and delivered on the deal's timeline rather than on a research schedule.

The review exists because the pitch deck describes the technology as the founders see it. The code, the incident history, and the team as it works from day to day describe the technology as it is. The difference between those two descriptions is the source of surprises after the deal closes. A 2016 Hacker News thread titled "Startup Technical Diligence Is a Waste of Time" reached 287 points, and the most-cited reply in it, from a reviewer who does the work for private equity funds, gave the reason for the review in one sentence: when a fund takes 51 percent or more of a company, it needs to be confident the technology will keep working.

Reveneau runs technical due diligence for investors as a standalone review before close, and it asks for the same three things on every engagement: read access to the repository, direct time with the engineers who built the system, and one working session where the target's own tests and evaluation suite run in front of the reviewer. A test suite that runs and fails is a finding. A test suite nobody can run is a larger one. The what is technical due diligence page defines the scope in full and separates it from a code audit, a penetration test, and a data room review.

How it works, step by step

A review follows a set order of steps, and that order matters more than any individual question on the checklist. The sequence below is the one this guide's how to run technical due diligence page turns into a full plan.

1. Write the thesis questions. Before anyone opens a repository, the deal team writes down the two or three technical assumptions the return depends on. "The platform serves ten times today's load without a rebuild." "The current team can deliver the roadmap without doubling." "The company can pass a SOC 2 audit within twelve months." Every part of the review tests those sentences.
2. Scope to the stage. A seed-stage review takes a day. A buyout review of a twenty-year-old platform takes weeks. The scope by stage page gives the depth for each stage, and the questionnaire is the request list that goes to the target.
3. Request the artifacts. The target opens a data room with the engineering material: an architecture diagram as it is today, the incident log, the release history, the dependency and licence inventory, the access model, current certifications with dates. The engineering artifacts for the data room page lists them. Andreessen Horowitz's 2022 guide to data rooms names five things a founder should include (deck, cap table, historical profit and loss, usage data, unit economics) and no technical category at all, which is why the engineering request has to be made separately.
4. Interview the engineers, then read the code. madewithlove, a firm that publishes its own process, describes a two-hour baseline interview with the CTO, a detailed reading of the codebase, follow-up interviews across the team, and a report, and states that it aims to finish within two weeks with up to eight interviews. The order matters: the interviews tell the reviewer where to look.
5. Verify what the thesis depends on. Watch the tests run. Read a real postmortem rather than the summary of it. Ask the engineers to explain the architecture live and compare it with the diagram. Mark each finding as verified or reported.
6. Price and rank. Every finding gets a cost in time and money, a confidence level, and a line saying what it means for the deal. The report structure and template page shows the layout. Start with what changes the price or the terms, then the first-hundred-days list, then the routine repairs.

What to check, and why the five areas are one system

The five areas are the same in every published framework, with small differences in naming. madewithlove assesses infrastructure, code quality, scalability, team and workflow, and security and compliance. Matt Van Itallie's 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. This guide uses five headings and reads them together, because a weakness in one area creates risk in another.

Code quality tells you whether the software is safe and cheap to change. The most useful measures come from DORA, the research programme that has published a software delivery study every year from 2014 to 2025 and describes itself as the longest-running academically rigorous investigation of its kind. Its five metrics are change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate. A team that can show those numbers for the last twelve months has told you more about its code than a style guide ever could. The assessing code quality page explains how to judge quality without reading the code yourself.

Architecture and scalability tell you whether the system can handle the growth being paid for. The AWS Well-Architected Framework names six areas, which it calls pillars (operational excellence, security, reliability, performance efficiency, cost optimisation, sustainability), and the reliability and cost areas are where diligence spends most of its time. A system whose running cost rises faster than its revenue has a scaling problem that shows in the cost figures, which is what the cloud cost due diligence page is for. The assessing architecture and scalability page covers the rest.

The engineering team is the asset that produces every future version of the code. Two well-documented effects matter in this part of the review. Brooks's law, from Fred Brooks's 1975 book The Mythical Man-Month, states that adding people to a late software project makes it later, because new people need time to learn the system and communication paths grow faster than headcount. And the bus factor, the number of people who would have to leave before a project stops, is low in most software: a study of 133 open source systems by Avelino, Valente and Hora found that 65 percent had a bus factor of two or fewer. The assessing the engineering team page covers how to measure both on a deal timeline.

Security and compliance tell you what liabilities you are buying. The OWASP Top 10:2025 lists the ten most common classes of web application weakness, from broken access control at A01 to mishandling of exceptional conditions at A10, and a review that maps the target's controls against that list has covered the common cases. The legal deadlines matter as much as the technical finding: the SEC's 2023 rule gives a public company four business days to disclose a material cybersecurity incident, and the UK ICO requires a personal data breach to be reported within 72 hours where feasible. The assessing security and compliance page explains the checks.

Technical debt is the extra work created by quick solutions chosen to save time, plus the extra cost those solutions add to every later change. Ward Cunningham, who created the term in 1992, described releasing first-time code as going into debt that "speeds development so long as it is paid back promptly with a rewrite". Stripe's 2018 survey of developers, by its own account, found the average developer spending 13.5 hours a week on technical debt and 17.3 hours on maintenance. The assessing technical debt page shows how to tell acceptable debt from debt that stops the roadmap from being delivered.

Two topics that now appear in every review

Open source licences. Morgan Lewis's June 2026 note on open source in M&A diligence lists the areas a buyer's counsel asks about: whether the company has a written open source policy, whether staff are trained on licence obligations, whether the company contributes code to outside projects, how it tracks the open source it uses, whether it scans the codebase, and how it handles software under copyleft licences such as the GPL. The Free Software Foundation's own FAQ states that a program linking to a GPL library must itself be released under the GPL or a compatible licence. The open source licence due diligence page covers the scan, the licence classes and the remediation options.

AI-written code. Most codebases reviewed in 2026 contain code that a model wrote. That is normal and is a finding only when it comes without a review record. Veracode's 2025 study of more than 100 language models found that 45 percent of generated code samples failed security tests, and Google's 2024 DORA report found that a 25 percent increase in AI adoption was associated with a 1.5 percent decrease in delivery throughput and a 7.2 percent decrease in delivery stability. The right question is whether the team has a verification method that catches what the model got wrong. Our AI-generated code to production hub covers that question in full, and the eval-driven development hub explains the evaluation suite a reviewer should ask to see running. For a company whose product is itself AI, the separate AI startup due diligence guide applies.

Common mistakes

Treating the review as a code audit. Code shows the system at one moment. A strong senior team with mediocre code is a manageable situation, because good engineers fix code. Excellent code with too few engineers stops improving as soon as the work gets hard or a key person leaves. Treat the team as the more important part.

Confusing the pitch with the system. Every company describes its own technology in the best possible way. The review reads the code as it is, the incidents as they happened, and the team as it works, and it separates what was verified from what was reported.

Grading instead of pricing. A codebase that needs six months of cleanup is a cost to raise in the price negotiation. Only a few findings, the ones on the warning signs page, move a deal from pricing to reconsidering.

Skipping the review for small investments. The Wiltbank and Boeker study of 539 angel investors and 1,137 exits found the median diligence effort was twenty hours, that 65 percent of exits with below-median diligence returned less than the money invested against 45 percent above the median, and that the top quartile, above 40 hours, achieved a 7.1X multiple. Hours are not the same as quality of hours, and the study measured diligence as a whole rather than technical diligence alone, but the pattern is clear. The angel investor technical due diligence guide covers what a one-hour and a one-day check can find.

Accepting an AI claim on the deck. In March 2024 the SEC fined Delphia $225,000 and Global Predictions $175,000 for misstatements about their use of AI, in what the SEC chair called "AI washing". In September 2024 the FTC announced five enforcement actions in Operation AI Comply. A claim about what the AI does is a claim to verify, and the how to verify an AI claim with a test page shows how.

Ignoring the report after close. The review's priced list is the first draft of the technology plan for year one. The technology after the deal guide covers how to turn it into the hundred-day plan and how to report engineering progress to the fund.

What it costs and how long it takes

All of the figures below are stated by vendors about their own services or their own survey of the market, so read them as vendor price ranges rather than as a measured average. MEV, a firm that publishes its pricing, states that its technical due diligence services range from $5,000 to $30,000 depending on the size and complexity of the system, quoted upfront, and take two to four weeks. Papermark's October 2025 survey of due diligence costs lists specialised technology firms at $300 to $600 per hour with typical project costs of $35,000 to $95,000, and Big Four technology advisory at $400 to $700 per hour with typical project costs of $50,000 to $150,000. Its worked example prices the technical review inside a $12 million enterprise value SaaS deal at $22,000. madewithlove states that it aims to finish within two weeks with up to eight interviews.

The range is wide because the work grows with the size of the codebase, the number of interviews, and the depth of verification the thesis needs. The what technical due diligence costs page breaks the price down by stage and by provider type, and the how to choose a technical due diligence firm page gives the questions to ask a vendor. Reveneau prices a review as a fixed scope quoted upfront, because the work is bounded by the thesis questions rather than by the size of the codebase, and because AI does most of the reading so the same review takes a small team.

Where to go next

If you are new to the discipline, start with what technical due diligence is. If you are in an active deal, go to the checklist, the questionnaire and the warning signs. If you are selling, sell-side technical due diligence and the founder-side guide to preparing for technical due diligence are the two to read. If the deal metrics and the engineering reality seem to disagree, SaaS metrics versus engineering reality is where to reconcile them. The one idea to keep in mind throughout: you are pricing risk against a thesis, and every finding should say what it costs and what it means for the deal.