What documentation does a startup need before demo day?

A one-page product vision, a technical architecture overview, your user research, a roadmap tied to outcomes, and your financials. Teams stumble here not for lack of good ideas but because the ideas live in people's heads rather than in something a mentor or investor can read and respond to.

What goes in a one-page product vision?

The problem and who has it, your solution and what makes the approach different, where you are now in terms of what is built and what traction exists, and where you are going over twelve months. Someone should read it in three minutes and understand the startup.

How long should these documents be?

Shorter than instinct suggests. One page for the vision, one page and a diagram for the architecture. The vision document is a filter: it should make someone want to ask questions, not pre-empt all of them. Resisting the urge to include everything is most of the work.

When should you write them?

Well before demo day, which in practice means starting around the eight-week mark rather than the final fortnight. The documents change what you build, not just how you present it, and that only helps if there is still time to act on what writing them reveals.

What happens if you leave it until the week before?

You discover the roadmap exists only as sticky notes and half-finished pages, usually at the moment an investor asks for it. That is recoverable in a week of focused work, but the week is taken from rehearsal and product, and any gaps the writing exposes go unfixed.

The Documentation Checklist Every Accelerator Team Needs 8 Weeks Before Demo Day

Your demo is in 8 weeks. What’s written down?

You’ve been heads-down building for months. The product works. The pitch is coming together. Mentors are giving feedback. Everything feels like it’s on track.

Then an investor asks for your product roadmap, and you realize it only exists as a collection of sticky notes and half-finished Notion pages.

This is where most accelerator teams stumble. Not because they don’t have good ideas, but because those ideas live in people’s heads instead of in documents that others can read, evaluate, and give meaningful feedback on.

Here’s what you need to have written down, well before demo day.

1. Product vision document (1 page)

This is the “what and why” in the simplest possible terms. One page. Not ten.

Cover these four things:

The problem you’re solving and who has it
Your solution and what makes your approach different
Where you are now (what’s built, what traction you have)
Where you’re going in the next 12 months

Investors and mentors should be able to read this in 3 minutes and understand your startup. If they can’t, the pitch won’t land either.

Resist the urge to include everything. This document is a filter. It should make someone want to ask questions, not answer all of them upfront.

2. Technical architecture overview

You don’t need a full system design document. You need a clear, one-page diagram and explanation of how your product works.

What to include:

High-level architecture (frontend, backend, database, third-party services)
Key technology choices and why you made them
Current scale (users, data volume, traffic)
Known technical debt or risks
What changes when you need to scale 10x

This matters because technical investors will ask about it, and “we’ll figure it out when we get there” isn’t a reassuring answer when they’re writing a cheque.

3. User research summary

Compile what you’ve learned from users into a single document. This doesn’t need to be academic. It needs to be honest.

Include:

How many users/customers you’ve talked to (be specific)
The top 3 problems they described in their own words
What surprised you (things you didn’t expect to hear)
How user feedback has changed your product decisions
Direct quotes that capture the pain points well

This document proves you’re building based on evidence, not assumptions. That matters enormously to investors who’ve seen too many startups build in a vacuum.

4. Product roadmap with milestones

This is where most teams are weakest. You might have a backlog or a list of features you want to build. That’s not a roadmap.

A roadmap should show:

Now (next 4 weeks): What you’re shipping before or at demo day
Next (months 2 to 3): Your immediate priorities post-funding
Later (months 4 to 12): Directional bets and bigger initiatives

For each phase, include specific milestones with measurable outcomes. Not “improve onboarding” but “reduce time-to-first-value from 15 minutes to under 5 minutes.”

Dependencies matter too. If feature B requires hiring a data engineer, say so. Investors want to see that you understand the sequence and the bottlenecks.

5. Financial model assumptions

You don’t need a sophisticated financial model at the accelerator stage. You need to show that you’ve thought about the numbers.

Document your assumptions:

How you plan to acquire customers and at what cost
Your pricing model and expected revenue per customer
Monthly burn rate (current and projected post-raise)
How long your runway lasts at current spending
What milestones you’ll hit before needing the next raise

Be honest about what’s an assumption and what’s backed by data. Investors respect founders who can say “we’re assuming a 3% conversion rate based on our landing page tests, but we haven’t validated it at scale.”

Why this matters now, not later

Every document on this list serves a dual purpose. First, it helps investors and mentors evaluate your startup and give you better advice. Second, it forces you to think clearly about things you might be fuzzy on.

I’ve watched teams go through the exercise of writing a product roadmap and realize halfway through that their cofounders don’t agree on the priorities. Better to discover that 8 weeks before demo day than during the investor Q&A.

The process

Don’t try to write all five documents in one weekend. Spread it over two weeks:

Week 1: Product vision and user research summary (these draw on what you already know)
Week 2: Technical architecture, roadmap, and financial assumptions (these require more analysis)

Share drafts with your mentors. Ask them to tell you where they’re confused, not where they agree. Confusion in the document means confusion in the pitch.

The bottom line

Documentation isn’t overhead for accelerator teams. It’s the difference between “interesting idea” and “fundable company.” The plans in your head are invisible to everyone who could help you. Write them down, and you’ll be surprised how much sharper everything gets.