The engineering data room: which artefacts go in which folder

An engineering data room is the folder of technical evidence you hand to an investor's reviewer, organised so that every item on their list has a place, and every place holds a real artefact or a dated note saying why it is empty. This page is the founder's side of that folder. The investor's side, what the reviewer expects to find and how they read it, is on engineering artifacts for the data room, and the pillar page on preparing for technical due diligence puts this page in the sequence.

Start with what the standard template gets you. a16z's "The Insider's Guide to Data Rooms", written by Justine Moore and published on 25 August 2022, lists five core components: pitch deck, cap table, historical P&L and burn, usage data, and LTV/CAC with payback period, plus category-specific metrics for marketplaces, social apps, subscriptions and e-commerce [3]. It mentions no code, architecture, engineering or security material. That is the template most founders follow, and it is why a technical reviewer so often receives a data room with nothing in it for them. Reveneau's preparation method treats the engineering data room as a separate folder with its own index, built from the reviewer's checklist rather than from the fundraising template, because the two lists have no overlap.

What folders should an engineering data room have?

Seven, following the seven headings of Matt Van Itallie's checklist of 26 October 2022, because a reviewer who did not write their own list has probably read that one [1]. Renaming the headings to what they contain gives:

Folder	Reviewer's heading	What it answers
01 Roadmap	Product roadmap	Does the team work on what the company says matters?
02 Code and architecture	Code quality	Can a team keep building on this?
03 Dependencies and licences	Intellectual property	Do you own what you sell?
04 Security	Code, network and information security	Can you keep what you hold?
05 Process and delivery	Development process	How does code get from a laptop to production?
06 Team	Engineering team contributions	Who knows what, and who else could?
07 Infrastructure	DevOps	What does it run on and what does that cost?

Number the folders so they sort in the reviewer's order, and put one file at the top level: 00-INDEX.md, described below.

What goes in each folder?

01 Roadmap. The ticket export for the last twelve months with a label per ticket (feature, maintenance, incident) and the computed split; a sample of raw customer feedback and the synthesis; the roadmap for the next twelve months. Van Itallie's checklist asks for all five [1]. The roadmap itself is a document with its own rules, covered on a technical roadmap for a fundraise.

02 Code and architecture. Repository access instructions (read-only, time-limited, revoked after the review); the last main-branch test run with its coverage report; the last static analysis report; the language list; the three architecture diagrams at three levels of zoom with the decision records behind them, per presenting your architecture to investors; and a one-page list of known technical debt with an owner and a plan for each item.

03 Dependencies and licences. A tool-generated dependency inventory with the licence of each entry and, for every copyleft entry, a column saying whether the component is hosted or distributed; the company's open-source policy if one exists; the IP assignment and confidentiality agreements for every employee and contractor who has committed code, or a list of contributors with the date each signed; the domain registrar record; the escrow agreement if any. Morgan Lewis's note of 5 June 2026 lists the open-source policy, monitoring and tracking of usage, regular scans, and an approval process for copyleft software among the six areas a buyer asks about [6].

04 Security. The incident log for the past three years (the window the checklist sets [1]), with root cause and fix per incident, or an empty log with a note on how incidents are recorded; the last vulnerability scan; the repository access policy with multi-factor authentication shown enabled; the last penetration test with each finding's remediation status; any certification (SOC 2, ISO 27001) with its date and scope; a data map saying what customer data is held, where, and under which legal basis. Our post on how to do a security review before launch covers producing the scan and the data map if they do not exist yet.

05 Process and delivery. The deployment log for the last quarter; the incident log cross-referenced to deployments; the five DORA numbers computed from those logs [8]; the branching and review conventions in one page; and a note on how many version control systems are in use and why, if more than one.

06 Team. The contributor list from the repository with join and leave dates; a table mapping each core system to the two people who can change it and when each last did; the plan for any row with one name; contractor agreements.

07 Infrastructure. The infrastructure diagram; the last three cloud invoices; the tool list with seat counts and annual cost; the on-premises and cloud split; planned improvements with their one-time and annual cost, which the checklist asks for by name [1].

What should the index page say?

The index page is the most-read document in the room, and a reviewer decides in the first ten minutes whether the rest is worth reading closely. Keep it to one page and give it four sections:

1. What is here. The seven folders, each with the list of files in it, one line per file.
2. What is missing. Every checklist item with no artefact, with the date by which there will be one, or "not applicable, because".
3. Known problems. The findings you would write about your own system if you were the reviewer: the single-owner system, the copyleft dependency, the module with no tests, the incident from last spring. Each with an owner, a plan and a date.
4. Contacts. Who answers questions on which folder, with the promise that every request is answered the same day.

Section three is the one founders resist writing, and it is the one that shortens the review most. A reviewer who reads a list of known problems on page one spends the week confirming your list rather than building their own. The investor-side page on technical due diligence red flags is a good source for what to put there.

What should you leave out?

a16z's guide names five things it would leave out of a fundraising data room unless an investor asks: an org chart or team bios, detailed three-to-five-year projections, tax returns and legal documents such as leases and offer letters, board minutes, and market sizing [3]. The engineering equivalents:

• Raw log dumps. Give the deployment log and the incident log for a quarter, with the computed numbers. Nobody reads a year of raw logs, and a reviewer who has to compute the numbers may compute different ones.
• Every diagram ever drawn. Three diagrams that match the code beat twenty that describe three different eras of the system.
• Aspirational documents. A security policy that describes controls you have not implemented is a finding, and it is worse than no policy, because it is a claim that can be checked against the engineer interviews.
• Full source in the room. Give repository access with an audit trail instead of a zip file. Access can be revoked; a zip file cannot.
• The five-year technical vision. The roadmap for twelve months, with the money attached, is what the reviewer reads. Anything beyond that is a slide, and slides go in the deck.

How do a16z's red flags apply to technical claims?

The same a16z guide lists four red flags a reviewer looks for in a data room: numbers inconsistent with the deck, numbers inconsistent across tabs or spreadsheets, limited historical data (its example is three months of history for a three-year-old company), and selectively presented metrics [3]. Each one has an engineering version, and the reviewer applies it.

a16z red flag	Engineering version
Numbers inconsistent with the deck	Deck says 99.95 percent uptime; status page and incident log say something else
Numbers inconsistent across documents	Coverage report says 71 percent; index page says 80
Limited history	One quarter of deploy logs for a company that has shipped for three years
Selectively presented metrics	The well-kept repository's test run in the room; the neglected one's absent

Before the room goes out, one person reads the deck, the financial model and the index page side by side and fixes every disagreement. That afternoon of work removes the class of finding that costs the most, which is the gap between account and system.

How should access to the room work?

Use a data room product or a locked shared folder with per-person access and an audit log, and give the reviewer read-only access with an end date. Repository access is separate: create a read-only account for the reviewer, scope it to the repositories in the room, and revoke it in writing when the review closes. Log who opened what; the log is also useful to you, because it shows which folders the reviewer spent time in and therefore where the questions will come from.

The two-week checklist schedules the building of each folder across the first week and the reconciliation pass across the second. The page on what a technical review asks for covers the one-sentence answer that accompanies each artefact.