FirstPlayable · Tools

Data Room Kit

30 items, six sections, one folder structure. Nothing is stored — your answers live in the URL.

Investors barely read data rooms. They check whether one exists, then spot-check the two things they actually care about. Build it for that behavior, not for completeness.

The existence of a data room is a signal about how the company is run. The contents matter in two places only — the cap table and the IP assignment — and those are where deals die, usually three weeks after everyone said yes.

The one-week version

If you are mid-raise and have nothing, do these three first and worry about the rest afterward: IP assignment from every contributor, a current cap table including undocumented promises, and a use of funds tied to a milestone rather than a date. Those three answer the questions that stop rounds. Everything else answers questions that merely slow them.

01 · Financials

Burn, runway, and what the money buys. The section founders under-prepare and investors read first.

Budget to the next milestone
Costed by role and month, ending at a milestone rather than a date.
Usually missing: A budget that runs to a date. Investors fund milestones; dates are how you get there, not what you are selling.
Done when
- The budget ends at a named milestone, and the milestone has a definition someone outside the team could verify.
- Every role that appears in the plan has a start month and a monthly cost.
- The total matches the amount being raised, or the difference is explained in a line.
Historical burn, monthly, actual
Last twelve months. Real outgoings, not budget.
Usually missing: Founder time worked unpaid. It makes burn look half what it is, and the investor who works that out has learned something about you that you did not choose to tell them. Show it as a line, valued at market, even if nobody was paid.
Done when
- Every month of the last twelve has a figure, including the months before the company had a bank account.
- The total reconciles to the bank statements to within a rounding error, and someone other than the person who built it has checked that.
- Unpaid founder time appears as its own line, at a market rate you can name.
Cash on hand and runway in months
One number, dated. Updated whenever you send the link.
Usually missing: The date. A runway figure without one is unreadable — the investor cannot tell whether it predates the last two months of spending. Runway decays daily, so an undated number is treated as the worst plausible number.
Done when
- The figure is dated, and the date is inside the last two weeks.
- Runway is calculated from the actual burn line, not from a planned budget.
- Someone has written down what the number becomes if the next raise slips by three months.
Founder compensation, stated
Who is paid, how much, from when. Including zero.
Usually missing: The point at which zero stops. A founder salary of nothing is credible now and a liability later — if the raise is silently expected to start paying three people market rate, that cost belongs in the budget the investor is reading, not in a conversation after the term sheet.
Done when
- Every founder has a stated figure, including the ones being paid nothing.
- The month unpaid founders start drawing a salary is written down, and that cost appears in the budget.
- Deferred or accrued founder pay is listed as a liability, or stated as waived in writing.
Projections in three scenarios
Downside, base, upside. Label the assumptions that separate them.
Usually missing: A single hockey stick. Three scenarios read as someone who has thought; one reads as someone who has hoped.
Done when
- Three scenarios exist, and each one names the specific assumptions that separate it from the others.
- The downside case still has the company alive at the end of it, or says plainly that it does not.
- Someone who is not on the team has read the assumptions and said which one they would challenge first.
Use of funds
What this specific money buys, and what is true when it is spent.
Usually missing: "Eighteen months of runway." That is not a use of funds. "To a shipped Early Access with X wishlists and Y retention" is.
Done when
- The document states what is true when the money is spent, not how many months it lasts.
- A reader can point to the sentence that names the outcome being bought.
- There is an answer to "what happens if you raise 70 percent of this" written down before anyone asks.

02 · Product

What it is, and whether anyone outside the building wants it.

Capture or trailer
Two minutes maximum. Real gameplay, not a sizzle cut.
Usually missing: A trailer used as evidence. A trailer proves you can make a trailer. Playtest data proves someone wants the game.
Done when
- The footage is real gameplay from the current build, not a target render or an older version.
- It runs two minutes or less.
- A viewer can tell what the player does from watching it with the sound off.
A short, current design document
Ten pages that match the build. Not eighty pages that match an older idea.
Usually missing: Agreement between the document and the build. The investor who reads both finds the mismatch in twenty minutes, and what it tells them is not that the design changed — every design changes — but that nobody on the team is responsible for keeping the written plan true.
Done when
- Someone has read the document and played the build back to back in the same week and listed the mismatches.
- Every mismatch is either fixed in the document or noted in it as a deliberate, dated change.
- It is under fifteen pages.
One paragraph a non-gamer understands
The person deciding may not play your genre. Write for them.
Usually missing: A paragraph written for someone who already plays the genre. It leans on references — roguelike deckbuilder, extraction shooter — that carry meaning for you and none for the partner who has to explain your game to an investment committee that has never heard of either.
Done when
- Someone who does not play your genre has read it and correctly described the game back to you.
- It contains no genre shorthand that a non-player would need explained.
- It fits in the body of an email without scrolling.
A playable build that actually runs
With instructions someone else has followed successfully, on a machine that is not yours.
Usually missing: A build that only works on the developer's setup. Test it on a clean machine before you send the link.
Done when
- The build has been installed and launched on a machine that has never had your project on it.
- A person who is not on the team followed the written instructions without asking a question.
- The instructions name the OS, the hardware minimum, and how long the install takes.
Playtest evidence
Sessions run, who they were, retention or completion, and the recurring qualitative themes — including the negative ones.
Usually missing: Everything. This is the single most under-supplied item in indie data rooms, and the one that most changes an investor's mind.
Done when
- The number of sessions, who the players were, and how they were recruited are all written down.
- At least one quantitative measure is reported for every session cohort, not just the ones that went well.
- The recurring negative themes are listed by name, with how many players raised each.
- A reader can tell which build version each session ran against.

03 · Team

Who is doing this, and are they actually doing it.

Bios tied to shipped titles
Role, scope, and what shipped. Not a list of employers.
Usually missing: Scope. "Worked on" a title with four hundred credited developers says nothing. What you owned, how big it was, and whether it shipped is the whole signal, and leaving it vague reads as hiding a small answer.
Done when
- Every bio names what the person owned, not only which company they were at.
- Each shipped title has a role and a scope next to it that could be checked with a credits search.
- Anyone whose most relevant work is unshipped or under NDA says so, rather than leaving a gap.
Founder commitment statement
Full time from when, and what happens to anyone still holding a job.
Usually missing: The other job. A founder with employment elsewhere is a normal, fundable situation right up until the investor discovers it themselves, at which point it becomes the thing they wonder what else you left out.
Done when
- Every founder has a full-time-from date, including the ones already full time.
- Any founder still holding other employment is named, with the date they leave it.
- Anything conditional on the raise closing says so plainly.
Key hires still needed
Roles, when, and what they cost. This is part of the use of funds.
Usually missing: How long each one takes to land. A senior engine programmer in a competitive market is a four to six month search, and a plan that has them productive six weeks after the money arrives is off by a quarter before it starts.
Done when
- Every open role has a start month, a monthly cost, and an expected search length.
- The search lengths are drawn from what your last hires actually took, or from a named market source.
- The plan still works if the hardest role to fill arrives a quarter late, or says what breaks.
Org chart with commitment marked
Who is full time, who is part time, who is a contractor. Dated.
Usually missing: The distinction. Investors assume everyone listed is full time until they discover otherwise, and discovering otherwise late is worse than saying it early.
Done when
- Every name carries full time, part time, or contractor, and the chart is dated.
- The part-time entries state how many days a week.
- Anyone appearing on the chart who is not yet contracted is marked as a hire, not as staff.

04 · Market

Which shelf this sits on, and next to what.

Audience defined by behavior
What they already play and where they find it. Not age brackets.
Usually missing: Where they find it. Knowing the player exists is half the answer; knowing which curator, subreddit, or streamer reaches them is the half that decides whether your launch budget does anything.
Done when
- The audience is described by what they already play, not by age or gender.
- At least three specific places they can be reached are named — a curator, a subreddit, a streamer, an event.
- Someone has checked that those places are active and sized, not just that they exist.
Wishlists, community size, mailing list
If they exist. If they do not, say so rather than omitting it.
Usually missing: The rate. A wishlist total is a number; wishlists per week, and what changed the week it moved, is evidence that you can influence the number. Investors fund the second one.
Done when
- Current totals are stated with a date.
- The rate of change is shown, not just the total.
- The weeks where the number moved are annotated with what caused the move.
- Channels you do not have are listed as absent rather than omitted.
At least one comp that failed
And a sentence on why yours is different.
Usually missing: The failure. A comp set of only successes tells an investor you have not looked hard.
Done when
- At least one comparable in the set underperformed, and the document says so directly.
- There is a sentence naming what went wrong for it, beyond "marketing".
- The sentence explaining why yours differs points to something already true in the build, not something planned.
Comparable titles with real numbers
Units, price, launch year, and where the figure came from.
Usually missing: A source. An unsourced comp is a guess with a chart on it.
Done when
- Every comparable has units or revenue, price, launch year, and a source a reader can open.
- The sources are named specifically enough to check, not cited as "public estimates".
- Every figure derived by estimate rather than taken from a source is labeled as an estimate.
Positioning in one sentence
Which existing game's audience you are taking players from, and why they would switch.
Usually missing: The name of the game you are taking them from. "For players who want a more accessible X" is positioning; "for players who love deep systems" is a description of everyone, and it tells the investor you have not decided who you are competing with.
Done when
- The sentence names a specific existing game whose players you are taking.
- It states why a player of that game would switch, in terms of what they do rather than how they feel.
- It survives being read aloud to someone who plays that game without them saying "but that already exists".

05 · Legal

The section that kills deals, three weeks after everyone said yes.

Current cap table
Every holder, every class, fully diluted. Dated.
Usually missing: Fully diluted. A cap table showing issued shares only hides the option pool, the SAFEs, and the convertible sitting in front of the new money — which means the ownership figure you are negotiating against is not the one that will exist after close.
Done when
- The table is fully diluted — options, pool, SAFEs, and convertibles all appear as lines.
- The percentages sum to 100, and someone other than the author has checked the arithmetic.
- It is dated, and the date is in the filename.
- Every vesting schedule shows start, end, and cliff.
Engine, middleware, and asset licenses
What you use, under what terms, and whether they survive a change of control.
Usually missing: Asset store licenses. Many are not transferable, and a few forbid commercial use at the tier that was bought.
Done when
- Every engine, middleware, plugin, and purchased asset in the project is listed with its license tier.
- Each entry says whether it transfers on a change of control.
- Any license that forbids commercial use at the tier bought is flagged, or confirmed absent.
- Someone has checked the list against what is actually in the project files, not against memory.
Founders' agreement and vesting
Reverse vesting on founder shares. Investors expect it; its absence is a negotiation you will lose later.
Usually missing: What happens when a founder leaves. The agreement that covers splits and titles but not departure is the one that fails on the day it is needed, and a co-founder holding thirty percent of a company they left two years ago makes the next round unraisable.
Done when
- The agreement is signed by every founder.
- It states what happens to shares when a founder leaves, for both good and bad leavers.
- Reverse vesting is in place, and the schedule matches what the cap table shows.
- The founder who would be most disadvantaged by the leaver terms has read them.
IP assignment from every contributor
Founders, employees, contractors, and anyone who touched it before the company existed.
Usually missing: The pre-incorporation code. Someone built the prototype before there was an AB, a contractor was paid without an assignment clause, an artist left in year one. This is the most common fatal defect in a small studio raise, and it is entirely preventable.
Done when
- Every name in the git history, the credits, and the payroll list appears in ip_assignments/, or is written down as a known gap.
- Anyone who contributed before the company existed has an assignment naming the company as the recipient.
- Each assignment is signed and dated, and the dates cover the period the work happened.
- Contractor agreements have been read to confirm they contain an assignment clause, not just a payment term.
Existing SAFEs, notes, grants, and their conditions
Including grant clawback terms and any publisher option or first-refusal right.
Usually missing: Grant conditions. Public funding often carries obligations that an investor will read even if you have not.
Done when
- Every outstanding instrument is listed with its amount, date, and conversion terms.
- Grant agreements have been read for clawback conditions, and those conditions are quoted rather than summarized.
- Any publisher option, first-refusal, or platform exclusivity right is named.
- The list says explicitly if it is empty.
Every promise that is not on the cap table yet
The contractor promised "a few points." The friend who helped early. Write them down even if undocumented — especially if undocumented.
Usually missing: These. They surface in diligence, and an investor discovering an undocumented equity promise assumes there are others.
Done when
- Every founder has been asked directly what they promised, and the answers are written down.
- The list includes promises the team believes are not binding.
- Each entry has a person, what was promised, roughly when, and who made it.
- The list says explicitly if it is empty, rather than the section being absent.

06 · Roadmap

Not the date. What the date depends on.

What is left, with confidence marked
High, medium, unknown. Naming the unknowns is a credibility signal, not a weakness.
Usually missing: The unknowns. A plan with no uncertainty reads as a plan written by someone who has not shipped.
Done when
- Every remaining area carries high, medium, or unknown.
- At least one area is marked unknown, or there is a written reason why nothing is.
- Each unknown says what would have to happen to make it knowable.
What would make it slip, and by how much
Two or three named risks with rough magnitude.
Usually missing: The magnitude. A risk register with no numbers on it is a list of worries. "Console certification, four to eight weeks, and it lands on top of the launch window" is a risk someone can plan around.
Done when
- Two or three risks are named, each with a magnitude in weeks rather than an adjective.
- Each risk names the early warning sign the team would see first.
- The magnitudes are consistent with the assumption costs in the timeline document.
What is done, verifiably
Tied to the build, so the claim can be checked in ten minutes.
Usually missing: The tie to the build. "Combat complete" is a status; "combat is what you play in the first ten minutes of the build, minus the third enemy type" is a claim someone can check — and the difference is what separates a roadmap from a wish.
Done when
- Every completed claim names where in the build a reader can see it.
- A person who is not on the team has checked two of the claims against the build and confirmed them.
- Anything complete in the document but not in the current build is marked as such.
Timeline with the assumptions written down
Nobody believes your date. They believe that you know what would break it.
Usually missing: The assumptions. This is the cheapest credibility available in the entire data room and almost nobody does it.
Done when
- Every assumption listed could turn out false — anything that cannot is a fact, and belongs elsewhere.
- Each assumption has a cost in weeks if it breaks.
- The assumptions have been read by someone who was not in the room when the date was set.

Folder structure

Copy this. Numbered so the order survives whatever tool you use, and so a reader knows where they are.

00_START_HERE.pdf              ← one page: what this is, who to contact, date
01_Financials/
   burn_actuals.csv
   runway_and_cash.pdf
   budget_to_milestone.csv
   use_of_funds.md
   projections_3_scenarios.csv
02_Product/
   one_paragraph.pdf
   build/  (link + instructions, tested on a clean machine)
   capture_2min.mp4
   playtest_results.pdf
   design_doc.pdf
03_Team/
   bios.pdf
   org_chart_and_commitment.pdf
   hiring_plan.pdf
04_Market/
   comparables.csv   (sourced, including one failure)
   positioning.pdf
   audience.pdf
   community_metrics.pdf
05_Legal/
   cap_table.csv     (fully diluted, dated)
   undocumented_promises.md
   ip_assignments/   (one file per contributor)
   licenses/
   safes_notes_grants/
   founders_agreement.pdf
06_Roadmap/
   status_verifiable.md
   remaining_work_with_confidence.md
   timeline_and_assumptions.md
   risks.md

Templates

Each item lists what finishing it requires — open Done when under any item above. Where a blank page is the real obstacle, there is a document to start from: the ten templates in the repository.

The items without a template are ones you verify rather than write. For those, the criteria are the whole job.

Three rules about the room itself

Date everything and put the date in the filename. An undated cap table is worth nothing; an investor cannot tell whether it predates the thing they just heard about.

One link, access controlled, with a log. Knowing who opened what and when is genuinely useful — it tells you which investor is actually working and which is being polite.

Never send a folder of loose files by email. It reads as a company that does not have a data room and assembled one in an afternoon, which is usually accurate.

How to score it

Count the boxes. There are 30.

Score	Read	What to do
0–11	Not raising yet, whatever the calendar says.	One week of work before any investor conversation. Start with section 05.
12–21	Raiseable, with a diligence problem waiting.	Find which of the missing items are in section 05 and close those first. The rest can be filled during the process.
22–28	Ready. Better than most of what investors see.	Focus on the two that most change minds: playtest evidence, and the timeline assumptions.
29–30	Unusually well prepared.	Make sure the build actually runs on a clean machine. It is the item most often checked and least often true.

01 · Financials

02 · Product

03 · Team

04 · Market

05 · Legal

06 · Roadmap

Folder structure

How to score it

Your data room, scored