The document
One to three pages.
Not a novel.
The best MVP documents are short. If yours is longer than three pages, the scope is too big — or you are documenting things that do not need to be documented yet. The spec covers what gets built in the next 8 weeks. Nothing more.
Hypothesis statement
One sentence. What you believe about the user, the problem, and the solution. "We believe [user type] will [action] because [reason]." This is the north star for every decision in the build.
User definition
One specific persona. Not a market segment — a person. "Solo freelance designers billing £40k–£80k per year who currently track projects in spreadsheets and send invoices manually." Specific enough to design for.
Feature scope and boundary
Two lists. In scope: the features that are being built. Out of scope: the features that are deliberately deferred. The out-of-scope list is more important — it is where scope creep gets caught before it starts.
Success metrics
The numbers that tell you whether the MVP worked. "100 signups in the first month. 30% complete the core action. 10% convert to paid." Specific, measurable, defined before launch.
Technical sections
The builder’s half
of the document.
The founder writes the first four sections. The development team adds the technical detail. Together, the document is complete.
01
User flow diagrams
The sequence of screens and actions from signup to value delivery. Not wireframes — flow diagrams. Boxes and arrows showing what the user does at each step, what choices they have, and where they end up.
02
Data model overview
The core entities and relationships. Users, projects, invoices, payments — whatever the product's data looks like. Not a database schema — a conceptual model that everyone can understand.
03
Tech stack decisions
Framework, language, database, hosting, payment provider, auth method. All decided and documented before development begins. Mid-build tech changes are expensive and disruptive.
04
Timeline with deliverables
Phase-by-phase breakdown. What gets built when. What the deliverable is at the end of each phase. When review points happen. When the product launches. Fixed dates, not estimates.
Template
The MVP document template.
Here is the exact structure we recommend. Each section is one to three paragraphs — not pages.
- Section 1: Hypothesis — one sentence describing what you believe and what you are testing
- Section 2: User — one paragraph defining the specific person this product serves
- Section 3: In-scope features — a numbered list of what gets built, described as user actions
- Section 4: Out-of-scope — a numbered list of what is deliberately deferred, with brief reasoning
- Section 5: User flow — a diagram showing the critical path from signup to value (boxes and arrows, not wireframes)
- Section 6: Data model — the core entities and their relationships (3–8 entities for a typical MVP)
- Section 7: Tech stack — one line per technology choice with brief justification
- Section 8: Success metrics — 3–5 specific numbers that define whether the MVP validated the hypothesis
- Section 9: Timeline — phase-by-phase with dates and deliverables
That is the entire document. Nine sections, one to three pages total. If every stakeholder can read it in 10 minutes and understand exactly what is being built, the document is doing its job.
Pitfalls
MVP document mistakes.
- Too long — a 20-page spec for an 8-week build means the scope is wrong. Cut the document, not just the features.
- No out-of-scope section — this is the most important section. Without it, every stakeholder assumes their favourite feature is included.
- Wireframes instead of flows — wireframes lock you into specific layouts too early. User flows are more flexible and more useful for development planning.
- No success metrics — the document defines what to build but not how to measure if it worked. Add metrics before development starts.
- Written in isolation — the founder writes the whole thing without technical input. The tech sections need developer involvement or the estimates will be wrong.
- Treated as permanent — the document is a starting point, not a contract carved in stone. If week 3 reveals that the flow does not work, the document adapts.
Timing
When to write the MVP document.
The MVP document is written during the scoping phase — before development begins. At Wall & Fifth, this is weeks 1–2 of the 8-week engagement.
You can start a rough draft before engaging a development team. Write the hypothesis, the user definition, and the in-scope features as you understand them. The technical sections — data model, tech stack, user flows — are best created collaboratively with the team that will build the product.
Do not wait for the document to be perfect before starting. A rough document that gets refined in week one is better than a polished document that delays the build by a month. The scoping phase exists to turn your rough ideas into a precise, buildable specification. Read our MVP process guide for the full week-by-week breakdown.
FAQ
Questions people usually have before the next step feels obvious.
What is an MVP document?
A specification defining what the MVP includes — hypothesis, user, features, out-of-scope list, tech decisions, success metrics. The contract between the idea and the build.
How long should it be?
One to three pages. If it is longer, the scope is too big.
What should it include?
Hypothesis, user definition, feature scope, out-of-scope list, user flows, data model, tech stack, success metrics, timeline.
Do I need one before hiring a developer?
Yes. Without it, you and the developer will have different expectations. The document prevents scope creep and aligns everyone.
Who writes it?
Founder writes the business sections. Developer refines the technical sections. At Wall & Fifth, we co-create it during the scoping phase.
Related pages
Write it together
We co-create the spec
during scoping.
You do not need to arrive with a perfect document. Tell us the idea and we will build the spec together during weeks 1–2. That is what the scoping phase is for.