How to prepare for technical due diligence: a founder's guide / Checklist

Checklist

The two weeks before a technical review: a preparation checklist

The two weeks before a technical review are enough to build the engineering data room, run the review on yourself, fix what can be fixed in ten working days, disclose the rest with a plan, and rehearse the walkthrough, if one person owns the work at half capacity and follows a list. This page is that list, day by day, with nothing held back for a download. It follows the seven headings of Matt Van Itallie's preparation checklist published in TechCrunch on 26 October 2022, adds the reconciliation pass that a16z's data room guide of 25 August 2022 makes necessary, and ends with the rehearsal. Print it, assign a name to each day, and start on day one with the investor's list in hand.

Published September 17, 2026. Editorial.

Key takeaways

Ten working days, one owner at half capacity, one spreadsheet with a row per item on the reviewer's list: that is the whole structure, and it is enough for a Series A review.
Week one builds: the answer spreadsheet, the seven data room folders, the team map, the dependency inventory, the scan and the diagrams. Week two reconciles, discloses and rehearses.
Day six is the reconciliation pass, where one person reads the deck, the financial model and the data room index side by side and fixes every number that disagrees, because that is the finding that costs most.
The fixes that take longer than two weeks (a second name on a core system, a copyleft replacement) go on the index page as known problems with dates, and the review proceeds without them.

The two weeks before a technical review are ten working days, and the list below assigns each one. It assumes one owner at half capacity, an investor's request list in hand (or the seven headings from Matt Van Itallie's checklist of 26 October 2022 as the substitute [1]), and a Series A-sized review. A seed review needs the first three days; a Series B review or a sale needs this list after the longer work described on preparing for a sale. The pillar page on preparing for technical due diligence explains the reasoning behind each item; this page is only the list.

Reveneau's preparation engagements run on this same ten-day list, with the owner on our side and the artefacts on yours, because the order of the days is what makes two weeks enough: the building happens in week one so that week two can be spent finding the disagreements between the artefacts, which is where every expensive finding lives.

What happens in week one?

Week one builds the artefacts. Each day below names what exists by the end of it.

Day 1: the list and the owner.

Name the owner. One person, with authority to pull engineers off other work for ten days.
Put the reviewer's list in a spreadsheet: one row per item, columns for artefact file name, one-sentence answer, owner, status ("attached", "none, due DATE", "not applicable, because").
If the investor sent no list, use the seven headings: product roadmap, code quality, intellectual property, security, development process, engineering team contributions, DevOps [1]. The page on what a technical review asks for expands each heading into its items.
Create the seven numbered folders of the engineering data room and an empty index page.
Create a read-only reviewer account for the repositories, scoped, logged, with an end date. Do not send it yet.

Day 2: the repository and the team map.

Search the full repository history for credentials, keys and tokens. If any are found, rotate them today and record the rotation; the history itself cannot be cleaned in two weeks, so disclose it.
Export the contributor list with join and leave dates.
Build the team map: one row per core system, the two people who changed it in the last year, the date each last did. Rows with one name go to the index page as known problems, with a plan and a date.
For each contributor, confirm a signed IP assignment exists. Missing ones go to the index page, and to a lawyer today.

Day 3: tests, scan and dependencies.

Run the full test suite on the main branch and save the run with its coverage report to folder 02.
List the modules with no tests and write one sentence per module saying why.
Generate the dependency inventory with a tool, with the licence of every entry, and mark each copyleft entry hosted or distributed. Save to folder 03. Morgan Lewis's note of 5 June 2026 lists tracking of open-source usage and regular scans among the six areas a buyer asks about [6], so the inventory's generation date is itself an artefact.
Run a security scan of the current code. Save the report to folder 04 with each finding's severity and status.
If a large share of the code was generated with AI tools, start the per-module table described on preparing an AI-written codebase for review.

Day 4: logs and numbers.

Export the deployment log and the incident log for the last quarter to folder 05, and the incident log for the last three years to folder 04, which is the window the checklist sets [1]. An empty incident log gets a note on how incidents are recorded.
Compute the five DORA numbers from the quarter's logs: change lead time, deployment frequency, failed deployment recovery time, change fail rate, deployment rework rate [8]. Write them on one page in folder 05.
Export twelve months of tickets, label each feature, maintenance or incident, and compute the split. Save the export and the split to folder 01.
Export the last three cloud invoices and the tool list with seat counts to folder 07.

Day 5: architecture and roadmap.

Draw the three diagrams from presenting your architecture to investors: context, containers, and components of the container that carries the risk. Draw the container diagram from the deployment configuration and the cloud console, which is what the reviewer checks it against.
Write the ten most important architectural decision records, dated today, and say in the index that they were written for the review.
Write the change table: each part of the system, the scale it fits until, what changes, the cost, the trigger.
Write or update the twelve-month roadmap in the six-column form from a technical roadmap for a fundraise, carrying forward the maintenance share from day four's split and adding a technical-debt line per quarter. Save to folder 01.

By the end of day five, every folder has something in it and the spreadsheet has a status on every row.

What happens in week two?

Week two finds the disagreements, fixes what can be fixed, writes down what cannot, and rehearses.

Day 6: the reconciliation pass.

One person reads the deck, the financial model and every artefact in the data room side by side, and lists every number or claim that appears in more than one place.
Fix every disagreement. The a16z data room guide of 25 August 2022 names numbers inconsistent with the deck and numbers inconsistent across documents as its first two red flags [3]; the engineering versions are an uptime figure in the deck that the incident log contradicts, a cloud cost in the model that the invoices do not match, and a coverage number on the index page that the report does not show.
Read the deck one claim at a time against the repository. Where the claim is ahead of the code, rewrite the claim. This is the cheapest fix on the list and the most expensive omission.
Walk the container diagram against the repository with an engineer who did not draw it. Move anything not in the code to a second diagram labelled "planned".

Day 7: fixes that fit in three days.

Add tests to the one untested module where a break would cost most, if it can be done by day nine.
Replace any copyleft dependency in distributed code where a drop-in replacement exists.
Enable multi-factor authentication on the repository and the cloud account if it is not already on, and record the date.
Fix the security scan findings marked high that have a known fix. Re-run the scan on day nine.
Everything that does not fit by day nine goes to the index page with a date. Single-name systems and copyleft replacements with no drop-in are the usual entries; what investors look for in a startup's codebase gives the fix times.

Day 8: the index page and the answers.

Write the index page: what is in each folder, what is missing with a date, the known problems with a plan and a date each, and who answers questions on which folder.
Write the one-sentence answer for every row in the spreadsheet. Artefact first, sentence second; where there is no artefact, "none, due DATE".
Check the stage. The page on what changes from seed to Series B says what a reviewer at your stage weighs most; make sure those rows are strongest.

Day 9: re-runs and the team briefing.

Re-run the test suite and the security scan; replace the day-three reports with today's.
Brief every engineer who might be interviewed: what the review is, the seven headings, who answers which topic, and that the correct answer to a question nobody can answer is "we will find out and send it today".
Choose three pull requests the reviewer might ask about (the largest, the riskiest, and one generated with AI tools if any) and make sure someone can walk each from the change to the check that ran to the result.
Send the reviewer account details and the data room access, so that the reviewer arrives on day eleven having read the index.

Day 10: the rehearsal.

Run the forty-five-minute architecture walkthrough to someone who has not seen it: five minutes on context, fifteen on containers with the deployment configuration open, ten on the risk-carrying component with the code open, five on decisions, ten on the change table.
Have the listener ask the eight reviewer questions from Van Itallie's list of 25 October 2022 [2]: what have you been working on, how much unit testing, does security match maturity, are the experts in the building, do you know your third-party code, can you explain variation across codebases, how much does finance invest in tech debt prevention, are you ready to learn. Each should be answerable by pointing at a folder.
Fix whatever the rehearsal exposed. Then stop.

What does the printable version look like?

The list above is the printable version, and this section is the one-page summary of it:

Day	Deliverable
1	Owner named; answer spreadsheet; seven folders; reviewer account created
2	Secrets search and rotation; contributor list; team map; assignment check
3	Test run and coverage; untested modules explained; dependency inventory; security scan
4	Deploy and incident logs; five DORA numbers; ticket split; invoices and tools
5	Three diagrams; ten decision records; change table; twelve-month roadmap
6	Reconciliation pass: deck, model and data room agree; deck claims match code
7	Three-day fixes; everything longer to the index page with a date
8	Index page; one-sentence answers; stage check
9	Re-runs; team briefing; three pull requests chosen; access sent
10	Walkthrough rehearsal; eight questions answered by pointing at folders

What if there is less than two weeks?

Do days one, two, six and eight, in that order, in whatever time there is. The list, the secrets search, the reconciliation pass and the index page are the four things that remove the findings that cost most, and together they take three days. Everything else on this list improves the review; those four prevent the review from going wrong.

What if there is more than two weeks?

Spend the extra time on the index page's known problems, starting with any single-name core system, because that is the finding that takes longest and reaches the report's first page. A month gives you time to add a second name to one system; a quarter gives you time for the copyleft replacement with no drop-in and the incident history that starts too late. Then run this list in the final two weeks anyway, because the reconciliation pass on day six catches what a longer preparation changes.

Best for

A founder or CTO with a technical review scheduled and a fortnight to prepare
The person named as owner of the preparation, who needs the work assigned by day
An investor who wants to send a company a plain schedule for getting ready

Avoid if

You are at seed and the investor has asked for an hour's conversation, where days one to three are enough
You are months out and want to fix the codebase rather than assemble the evidence

Verify before you commit

By day five, every folder has an artefact and every spreadsheet row has a status
By day six, the deck, the financial model and the data room index agree on every shared number
By day nine, the reviewer has access and the index page lists every known problem with a date

Common questions

What should I do in the two weeks before a technical due diligence review?

In the two weeks before a technical due diligence review, spend week one building the artefacts (the answer spreadsheet, the seven data room folders, the team map, the dependency inventory, the test run, the security scan, the logs and their numbers, the diagrams and the roadmap) and week two reconciling them against the deck, fixing what fits in three days, writing the index page, briefing the team and rehearsing the walkthrough. The folders follow Matt Van Itallie's 2022 TechCrunch checklist.

Is two weeks enough to prepare for technical due diligence?

Two weeks is enough to prepare for a Series A review if one person owns the work at half capacity and follows a day-by-day list, because building the seven data room folders takes five days and reconciling, disclosing and rehearsing takes five more. It is enough for a seed review with days to spare. It is the final fortnight of a longer preparation for a Series B or a sale, where the incident history and the ownership work start earlier.

What is the first thing to do when preparing for a technical review?

Name the owner and build the spreadsheet. One person with authority to pull engineers off other work for ten days, and one row per item on the reviewer's list with columns for artefact, one-sentence answer, owner and status. If the investor sent no list, use the seven headings from Van Itallie's checklist of 26 October 2022: product roadmap, code quality, intellectual property, security, development process, engineering team contributions and DevOps.

What is the reconciliation pass in due diligence preparation?

The reconciliation pass is one person reading the deck, the financial model and every artefact in the data room side by side, listing every number or claim that appears in more than one place, and fixing every disagreement. a16z's data room guide of 25 August 2022 names numbers inconsistent with the deck and numbers inconsistent across documents as its first two red flags. The pass takes one day, day six on this checklist, and removes the class of finding that costs most.

Which fixes fit in the two weeks before a technical review?

Tests on one untested module where a break would cost most, a drop-in replacement for a copyleft dependency in distributed code, multi-factor authentication on the repository and cloud account, and the security scan findings with a known fix. Those fit in the three days from day seven to day nine. A second name on a core system takes four to six weeks and a copyleft replacement with no drop-in takes longer, so those go on the index page with a date.

When should I send the reviewer access to the data room?

On day nine, two working days before the review starts, after the re-runs of the test suite and the security scan have replaced the earlier reports and the index page is written. A reviewer who arrives having read the index page asks better questions and runs a shorter review. Send a read-only repository account that is scoped, logged and has a written end date, created on day one and held until the room is ready.

How should I brief engineers before a technical due diligence review?

Tell every engineer who might be interviewed what the review is, the seven headings the reviewer will use, who answers which topic, and that the right answer to a question nobody can answer is that you will find out and send it today. Reviewers interview engineers separately from founders, and the interviews are where a gap between the data room and the system shows first, so the briefing should also cover what the data room says about each engineer's area.

What should the walkthrough rehearsal cover?

The forty-five-minute architecture walkthrough, given to someone who has not seen it, followed by the eight reviewer questions from Van Itallie's TechCrunch list of 25 October 2022: what have you been working on, how much unit testing, does security match maturity, are the experts in the building, do you know your third-party code, can you explain variation across codebases, how much does finance invest in tech debt prevention, and are you ready to learn. Each should be answered by pointing at a folder.

What if I have less than two weeks before a technical review?

Do days one, two, six and eight of the checklist in that order: the answer spreadsheet and folders, the secrets search and team map, the reconciliation pass, and the index page with the one-sentence answers. Those four take three days together and remove the findings that cost most, which are credentials in the history, an undisclosed single-name system, and a gap between the deck and the code. Everything else on the list improves the review; those four prevent it going wrong.

Do I need to download a template for the two-week checklist?

No. The full day-by-day list is on this page, with a one-page summary table, and nothing is held behind a form. Print the page, write a name against each day, and start on day one with the investor's request list or the seven headings from Van Itallie's checklist of 26 October 2022 as the substitute. The deliverables per day are in the table, and each links to the page in this guide that explains how to produce it.