Technical due diligence scope by stage: seed, Series A, Series B, buyout

Technical due diligence scope follows the question the stage asks, and getting the question right is most of the scoping. A seed investor who runs a buyout review wastes money and annoys the only people who know how the product works. A buyout team that runs a seed review inherits a licence problem and a cloud bill nobody read. The scope in the table below is built so that each stage answers its own question at the depth that question needs.

Reveneau scopes a review by stage before scoping it by codebase, and states in the proposal which of the four questions below the review will answer, because a quote for "technical due diligence" without that sentence describes a product the investor may not need. The founder facing the same review at each stage has a separate page: technical diligence scope by stage for founders, in the preparation guide.

This page assumes the pillar guide and the five assessment pages in it. The cost figures below are vendor-stated and attributed, and what technical due diligence costs puts every one of them side by side.

How does the question change from seed to buyout?

The question changes from the people to the product to the organisation to the inheritance, and the table sets out what follows from each. Every row is a starting point to cut down for a specific deal, and the price column repeats the vendor-stated bands from the cost page so the reader can see which product each stage buys.

	Seed	Series A	Series B and growth	Buyout
The question	Can these founders build what they describe, and is anything already built a liability?	Can this product carry ten times the users and the team keep shipping while it does?	Can this organisation carry the plan: hiring, process, security, cost?	What is the buyer inheriting, what does it cost to fix, and what goes in the agreement?
Depth	A repository walk-through with the founders, one to three hours	Code reading, three to eight interviews, a written report	Everything at Series A plus delivery metrics, security reports, cloud bill and roster	Everything at Series B plus open source inventory, contractual commitments, account ownership and a risk register for counsel
Artefacts	Read access to the main repository; a demo against real data	Repositories, architecture as used, incident log, test suite, team list	Add pipeline metrics, penetration test reports, twelve months of invoices, attrition	Add licence scan, commitment contracts, customer commitments, IP assignments, all eight data room folders
Who does it	The investor's most technical partner or a trusted engineer	An outside reviewer or an experienced in-house technical partner	An outside reviewer with a security specialist available	An outside firm, with counsel receiving the register
Duration	Half a day	Two to four weeks (MEV, updated 2026-08-05); within two weeks with up to eight interviews (madewithlove, 2024-05-03)	Two to four weeks, often at the upper end	VeryDiligent's large tier: multiple products, large teams, regulatory requirements (2026-06-04)
Vendor-stated price band	Often none; a screen where paid: Dextralabs Dipstick $5,500 (updated 2026-09-02)	MEV $5,000 to $30,000; VeryDiligent standard 20,000 to 30,000 euros	Papermark specialist $35K to $95K (2025-10-27)	Papermark Big Four $50K to $150K; VeryDiligent 30,000 to 50,000 euros and up
Deliverable	A note to the partnership and a list of what to check at the next round	A report to the template on this site: summary, findings, cost to fix, unverified list	The same, with a risk register and a 100-day recommendation	The full report plus a lender-ready summary and a schedule for the agreement

The table simplifies. A seed company with a regulated product, a Series A built on an acquired codebase, or a growth round in an AI company with inference at a quarter of revenue each pull scope from a later column. The stage sets the default and the thesis adjusts it.

What does a seed review look like?

A seed review is a conversation with the founders in front of the code, and its purpose is to find out whether they can build and whether anything already built will have to be thrown away. Y Combinator's A Guide to Seed Fundraising says it from the other side: "Do not spend too much time developing diligence documents for a seed round. If an investor is asking for too much due diligence or financials, they are almost certainly someone to avoid."

That advice is right, and it leaves a gap, because most angel-group guidance has no technology content at all. The Angel Capital Association's due diligence guidance (2007) has no technology section, and the UKBAA's 2020 guide asks eight technology questions that are all about positioning and IP. The angel guide on this site fills the gap with the one-hour technical check, and the single most useful fact about seed diligence comes from Wiltbank and Boeker's November 2007 study of 539 angels and 1,137 exits: investors above the median twenty hours of diligence saw a 5.9X overall multiple against 1.1X below it. That is all diligence, self-reported, and it is the reason to spend the half day rather than skip it.

At seed the review does three things: opens the repository and reads enough to see whether the code matches the description, watches the product run against real data rather than a demo dataset, and asks who wrote what. It ends in a note to the partnership and a short list of what to check at the next round.

What changes at Series A?

At Series A the review starts reading code and interviewing engineers, because the question has moved from the founders to the product, and the answer needs artefacts. This is the stage where a written report first earns its cost, and where the vendor-stated durations apply: MEV states two to four weeks and madewithlove states within two weeks with up to eight interviews.

The review covers the five areas in the pillar guide: code quality, architecture and scalability, the engineering team, security and compliance, and technical debt. The artefacts are the repositories, the architecture as the team uses it, the incident log, the test suite and the team list. The deliverable is the report on the template page, with the cost-to-fix table doing the work that matters, because the thesis at Series A is that the money buys growth and the report says how much of it buys repair instead.

Key-person risk is the finding that most often changes a Series A. A product carried by one engineer is a product that can leave.

What does Series B and growth add?

Series B adds the organisation: delivery metrics, security evidence, the cloud bill and attrition, because the question is whether the company can carry a plan that now involves hiring, process and cost at a scale the founders have not run before.

Three artefacts join the request. The pipeline's delivery metrics (DORA's change lead time, deployment frequency, change fail rate and recovery time) give a measured pace to check the roadmap against. The penetration test report and any certification reports turn security from a claim into a document. And twelve months of cloud invoices give the unit cost trend; cloud cost due diligence walks the bill. This is also where SaaS metrics and engineering reality get reconciled, because the price is now a multiple of ARR and the review has to confirm the platform produces it.

The deliverable adds a risk register and a recommendation for the first 100 days after the round, since a growth investor usually has a board seat and a plan to influence.

What does a buyout require that a venture round does not?

A buyout requires the full inheritance to be listed and priced, because the buyer takes on every contract, licence, account and commitment the company has, and has no founder with a stake left to fix what was missed.

Four things join the scope. The open source inventory and scan, because licence obligations attach to distributed and served software and Morgan Lewis's note of 2026-06-05 observes that scans often find issues that have to be fixed before closing. The commitment contracts, because savings plans and committed use discounts run one or three years and expire on dates the new owner has to know. The customer commitments, because features promised in writing are engineering work with a legal deadline. And account ownership, because production in an individual's cloud account is an asset that depends on a person.

The deliverable feeds counsel directly: a risk register with a proposed contractual treatment for every High and Critical finding, and a list of what could not be verified for the warranties. Sell-side technical due diligence is the same review run by the seller in advance, and a buyer who receives one still runs their own on the same scope. After close, the technology workstream in a 100-day plan turns the register into a schedule.

How should an investor cut the scope for a specific deal?

Cut the scope by starting from the stage's column and adding rows from a later column wherever the thesis depends on them. The three common additions are a regulated product at any stage (add the security and compliance depth from Series B), an acquired or inherited codebase at any stage (add the open source and IP rows from buyout), and an AI product where inference is a large cost (add the cloud and margin rows from Series B and the AI startup guide).

Then write the scope down and send it with the request for quotes, because a firm that receives a one-page scope prices the product the deal needs, and a firm that receives "technical due diligence" prices the product it sells.