What goes in a deep tech data room, and how to design it
The deck makes the claim; the data room holds the measurement. Six folders, what changes from Seed to Series B, and a way in for partner and reviewer.
- A deep tech data room holds the evidence behind the deck, including technical results a specialist can check against the conditions that produced them.
- Organise it in 6 folders: company, technical evidence, IP, commercial, team and financials. For a physical product, keep the test method beside every result.
- At Seed, show what the prototype has demonstrated and what is still unproven. By Series B, add pilot, production and commercial evidence.
- Label every result measured, modelled or projected, link each deck claim to its document, and give generalist partners and technical reviewers separate reading paths.
A deep tech raise is won in the deck and checked in the data room. Most data rooms are assembled in a hurry from folders nobody designed, which is how a sound company ends up looking like an unmanaged risk.
What is a data room, and why does a deep tech company need a different one?
A data room is the evidence behind the pitch, organised so an investor can check it without the founder in the room. For a hardware, materials, energy, robotics or semiconductor company, that evidence includes physical test results and the conditions that produced them, alongside the usual company and financial records.
The standard frameworks do not separate those records. Affinity's guide to venture due diligence groups the review into team, business, market, technology and product, finance and tax, and legal. A deep tech room needs lab measurements, IP and manufacturing readiness findable on their own, because a reviewer tests each claim against a different kind of evidence.
A prototype test establishes performance under stated conditions. It does not establish that the product will perform the same way in the field or at production volume, and the room should say so where the work is unfinished.
What folders go in it, and how do they change from Seed to Series B?
Six folders cover it: company, technical evidence, IP, commercial, team and financials. At Seed, each folder shows what has been done and what remains unproven. By Series B, investors need records that let them check repeatability, adoption and the cost of scaling.
| Folder | Seed | Series A | Series B |
|---|---|---|---|
| Company | Incorporation and ownership records, current financing plan | Updated cap table, board materials, signed financing documents | Full corporate record and material agreements |
| Technical evidence | Prototype description, test methods, raw results, known limits | Repeat tests, independent validation where available, pilot results with conditions | Field performance across deployments, failure records, production units against the tested specification |
| IP | Invention records, any filings, founder and employee assignment agreements | Updated filings, licence terms, rights from joint development | Patent status, material licences, ownership across subsidiaries and partners |
| Commercial | Customer interviews, letters of intent, the problem each buyer wants solved | Pilot agreements, customer feedback, evidence of willingness to pay | Signed contracts, renewals, deployment costs and obligations |
| Team | Founder roles and the expertise the next milestone needs | Key hires, advisers, who owns development and testing | Leadership responsibilities and capacity to support production |
| Financials | Spend to date, cash position, forecast tied to technical milestones | Actuals against plan, forecast assumptions, pilot economics | Audited accounts if available, revenue, production cost, cash needs |
This is a working structure, not a published investor standard. Software-oriented guides such as Nulab's on technical due diligence centre on architecture, scalability and security. A physical product also needs the reviewer to see how each measurement was taken, which units were tested, and whether pilot conditions resemble real use.
How does the deck connect to the data room?
The deck states the claim and the data room holds the evidence behind it. Every number in the deck should trace to a dated document: a test report with its conditions and sample size, a customer commitment, or a forecast with its assumptions.
Label each technical result as one of 3 things:
- Measured: what a test observed under stated conditions.
- Modelled: an estimate of performance outside those conditions, built from observations and assumptions.
- Projected: an expected future outcome, such as a target for a later production run.
A projection presented as a measurement sends the reviewer looking for test evidence that does not exist. Affinity notes that investors who are not experts in a field recruit experts they trust to evaluate it, so the distinction has to survive someone who has never heard the founder explain it.
Keep one verified record of each claim, with its source, date, status, assumptions and limits, and update both the deck and the room from it. We set out what belongs in the deck itself in how to build a pitch deck investors without a deep tech background can understand.
How should the room itself be designed?
Give it an index, consistent file names and 2 reading paths. The index links each deck claim to its supporting document and names the owner, date and current version. A name such as Cycle_test_v03 tells a reader which result superseded which without opening both files.
A generalist partner needs a short reader's guide: where to start, and what each folder can and cannot establish. It can point to a pilot report as evidence of performance under stated conditions while saying plainly that the pilot does not establish production at scale. The technical reviewer needs a direct route to methods, raw readings, calculation assumptions and versioned results.
Restrict sensitive files without hiding the evidence a claim depends on. Most data room tools let you gate access behind an NDA, watermark files and see which documents were opened. An open tells you someone looked, not that they understood or accepted what they saw.
What mistakes slow deep tech diligence down?
Three structural mistakes do most of the damage, and each reads as unmanaged risk even when the work underneath is sound.
- No index. The reviewer has to rebuild the argument behind the deck. An index and reader's guide do it for them.
- Measured and projected figures mixed together. A reviewer cannot check a claim whose status is unclear. Label it and link it.
- A gap in the IP chain of title. Keep the ownership records in the IP folder and make any open question visible, so it is assessed early rather than discovered late.
What else do founders ask about data rooms?
How big should the room be? Big enough to support the claims made at this round, not a target document count. A Seed room may hold prototype results; a Series B room makes pilot and production claims traceable to their records.
Who gets access, and when? Prospective investors get what they need to assess the first claim. Technical reviewers get methods and raw results when technical diligence starts. Sensitive IP and customer records go only to the people reviewing them.
Does the room need updating between rounds? Yes. Replace outdated forecasts, add new test and pilot evidence, keep dated versions where a claim changed, and check the deck still points at the current documents.
A well-built room shortens diligence because a reviewer can check a claim without waiting for the founder to explain it. It cannot supply evidence that does not exist, but it stops a strong company losing weeks to avoidable questions. For the slide that has to carry the mechanism, see what a prototype proves and what the commercial case needs.
Written by Mejo Kuriachan. More in the blog, the glossary and the FAQ.