What changes in technical diligence from seed to Series A to Series B

Technical diligence changes by stage in three ways: how deep the review goes, who runs it, and what counts as a finding. Preparation should change the same way. Over-preparing at seed wastes weeks the company does not have; under-preparing at Series B hands the reviewer a month of questions. This page is the founder's side of that scaling. The investor's side, with the table of what a reviewer checks at each stage, is on technical due diligence scope by stage, and the pillar page on preparing for technical due diligence puts this page in sequence.

Reveneau's preparation method scales the same way, from a repository walkthrough at seed to the full seven-folder data room at Series B, because the review a company is preparing for is the one its investor will run, and a seed investor who receives a Series B data room learns only that the founders spent their time on the wrong thing.

What does technical diligence look like at seed?

At seed, technical diligence is usually short, often informal, and centred on the product working and the founders being able to explain it. Y Combinator's "A Guide to Seed Fundraising", by Geoff Ralston, says it plainly: "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." The same guide says a founder will probably want an executive summary and a slide deck, and little else [4].

That is the investor community's own position on seed-stage documents, and it should set your preparation. What a seed reviewer does, when there is one, is a demonstration of the product against real data, a look at the repository for signs of care (a test directory, a readable commit history, no secrets in the tree), and a conversation with the technical founder about how the system is built and what would break first. Angel groups' reviews are described from the investor's side on the one-hour technical check and MVP diligence.

Preparation at seed is four things. A demo that works on the day, against data that is not a fixture. A repository with no credentials in its history, which takes an afternoon to check and a week to fix if the answer is wrong. A single page saying what the system is, in the words of the container diagram from presenting your architecture to investors. And a technical founder who can answer "what would break first if you had ten times the users?" without a slide. Our guide to launching a product MVP covers getting the product to the point where that demo is possible.

How much time the investor spends matters too. Wiltbank and Boeker's November 2007 study of 539 angel investors and 1,137 exits found the median due diligence before an angel investment was 20 hours, with a mean of 60, and that exits with above-median diligence returned an overall 5.9X against 1.1X below the median [5]. Angels who know that study spend the hours. Twenty hours is enough to read a repository, so a clean one matters even at seed.

What changes at Series A?

At Series A, the review gets a reviewer. Either the fund has a technical partner who spends days in the repository, or it hires an outside firm, and either way the review has a list. The list is close to Matt Van Itallie's TechCrunch checklist of 26 October 2022, with its seven headings: product roadmap, code quality, intellectual property, security, development process, engineering team contributions and DevOps [1]. Our page on what a technical review asks for goes through it item by item.

What the Series A reviewer weighs most, from the founder's side:

• Tests that run on every change. The reviewer runs the suite and reads the last few main-branch runs. A suite that exists and is green on every pull request is the single strongest signal at this stage.
• A dependency inventory with licences. Generated by a tool, with every copyleft entry marked hosted or distributed. This is the first stage at which a licence finding becomes a condition of the round.
• A team map. Each core system with the two people who can change it. At Series A there is usually one system with one name, and the reviewer will find it in the commit history. Disclose it with a plan.
• Three architecture diagrams that match the code, and a short list of what you would change at what scale.
• A twelve-month roadmap tied to what the round buys, per a technical roadmap for a fundraise.

The data room at this stage is the seven folders described on the engineering data room, with the honest expectation that several items are marked "none, due DATE". A Series A reviewer expects gaps and reads the list of them as evidence that you ran the review yourself.

What changes at Series B?

At Series B, the review runs for weeks, the reviewer is almost always an outside firm, and the standard moves from "is there a practice" to "show me the history". Three things change most.

History replaces existence. Van Itallie's checklist asks for incidents within the past three years, twelve months of development activity by repository, and twelve months of product management data split between features and maintenance [1]. At Series A, a reviewer accepts that the incident log started six months ago. At Series B, a three-year-old company with six months of incident history has a finding, and a16z's data room guide of 25 August 2022 names limited history as a red flag in exactly those terms, with three months of financials for a three-year-old company as its example [3].

Numbers replace descriptions. The reviewer computes DORA's software delivery metrics from your deploy and incident logs: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate [8]. Then they read the roadmap against those numbers and against the hires the round pays for. A roadmap whose dates assume a delivery rate the logs do not show is a finding at this stage, where at Series A it was a question.

Security evidence becomes formal. A penetration test with each finding's remediation status, a certification with its scope and date if customers require one, a data map with legal basis per data type, and the repository access policy with multi-factor authentication shown enabled. The investor-side page on assessing security and compliance describes what the reviewer does with each. The single-name system that was a disclosure at Series A is, at Series B, a finding that the company has known about for eighteen months and not fixed, so fix it before the round.

How should preparation scale with the stage?

The table below is the founder's side of the stage scaling. The investor's table is on technical due diligence scope by stage.

	Seed	Series A	Series B
Who reviews	Angel, technical partner, sometimes nobody	Technical partner or outside firm, days	Outside firm, weeks
What the product must do	Demo against real data	Demo plus repository walkthrough	Run in production with three years of evidence
Tests	A suite exists and is green	Runs on every change; untested modules explained	Coverage history; delivery metrics computed from logs
Dependencies	No obvious copyleft in distributed code	Tool-generated inventory with licences	Inventory, open-source policy, scan history
Team	Founder can explain the system	Team map; single-name systems disclosed with a plan	No single-name core systems; contributor history
Security	No secrets in the repository	Scan report; access policy	Penetration test, certification if required, data map
Roadmap	One page	Twelve months, tied to the round	Twelve months, checked against measured capacity
Preparation time	Days	Two weeks	Four weeks or more

Two rows deserve a note. The "who reviews" row at seed includes "sometimes nobody", and that is consistent with Y Combinator's advice [4]; a seed investor who runs a Series B review is the one the guide says to avoid. And the preparation-time row is one person at half capacity, which is the assumption behind the two-week checklist for Series A.

What does not change by stage?

One thing, and it is the thing that costs most. At every stage, a gap between what the founders say and what the reviewer finds is the finding that puts every other claim under suspicion. Van Itallie's eighth question, "Are you ready to learn and grow?" [2], is the seed version, asked in a conversation; at Series B it is asked by reading the deck against the repository, box by box. The preparation is identical at every stage: read the deck one claim at a time, check each against the code, and where the claim is ahead, rewrite the claim.

The second constant is disclosure. A known problem with a plan is a line item at seed, at Series A and at Series B. The same problem found by the reviewer is a trust problem at every one of them. The investor-side page on technical due diligence red flags is a good list of what to disclose, whatever the stage.

What if the company is raising a Series A on a seed-stage codebase?

Then say so, and show the plan. A company that grew faster than its engineering practices is a common Series A shape, and a reviewer is used to it. What the reviewer needs is the list of what a Series A codebase would have that this one does not (tests on the billing path, a second name on the data pipeline, a licence inventory), the order in which you will add them, and the roadmap line that pays for it. A company that presents that list has run the review on itself. A company that presents a seed-stage codebase as a Series A codebase has created the gap this page keeps returning to, and the reviewer will find it in the first day. Our guide to scaling engineering teams covers the practices a growing team needs to add and in what order.