An MVP scope document needs five things: the problem and who has it, the user types and their most critical action, three to five features that test the hypothesis, an explicit non-goals list, and one measurable success condition. One page. If it doesn't fit on one page, the build isn't scoped yet.
Why does a scope document change the quality of the quotes you get?
Most founders get wildly different quotes — one studio at $15,000, another at $75,000 — and assume one is gouging and one is undercutting. Usually neither is true. They're quoting two different products.
Without a scope document, every studio fills in the gaps with its own assumptions. A "marketplace with payments" is a $20,000 build to one shop (Stripe Checkout, two user types, a basic admin) and a $65,000 build to another (Stripe Connect, three user types, a reporting layer, a custom dashboard). Neither is wrong — they just read a different product into the same brief.
A precise scope document produces quotes within 15–25% of each other. A vague brief produces quotes that span 5×. The scope document is the instrument of comparison, not the contract.
What are the five sections of a one-page MVP brief?
| Section | What it covers | What makes it specific |
|---|---|---|
| Problem + who has it | The exact problem, and a named persona | "Independent US physiotherapists who manage 30+ sessions weekly" beats "healthcare" |
| User types + critical action | Every role that logs in, and their one most important action | "Patient: books a slot. Therapist: confirms and adds notes. That's v1." |
| Features (3–5) | The minimum surface that tests the hypothesis | Only what survives the three-question filter below |
| Non-goals | What the build explicitly will not do | "No mobile app, no insurance billing, no patient messaging" |
| Success metric | One measurable condition | "10 therapists paying $49/month after 60 days of live use" |
The non-goals section is as important as the features list. Every assumption left unstated becomes a scope conversation mid-build.
What belongs in the features list — and what doesn't?
Every feature should survive three questions in order:
- Does it test the core hypothesis? If you're testing whether therapists will pay to automate scheduling, group bookings don't test that — they extend the product past the hypothesis.
- Can the product be tested without it? If removing a feature makes the MVP impossible to use, it belongs. If removing it only makes the product less complete, it probably doesn't.
- Did a real user specifically ask for it? Not "someone probably wants this" — a named person in a real conversation asked for it.
A feature that fails any one of those three questions goes on the deferred list. A feature on a list costs nothing. A feature in the build costs development time, test coverage, and permanent maintenance.
Across the forty-plus briefs we evaluate each year, the initial feature list almost always comes in at 20–35 items. After the three-question filter, the real launch set is usually 5–12. On LaunchProd, four of the original forty-two features were never rebuilt after launch — users didn't ask for them once the core product existed.
How do you handle a change request once the brief is signed?
Re-price in writing at the first material change.
This isn't adversarial. A change-order process is what separates an engagement that ran long from one that lost money quietly on both sides. Every studio that swallows scope changes without raising the conversation is accumulating a debt that shows up later as a missed deadline, a tense call, or a rushed final week.
A clean change order has three parts: a written description of what changed, a time and cost estimate for the addition, and a clear acknowledgment before work starts. An email thread with an explicit "yes, proceed" counts. What matters is that both sides agreed, not that it passed a legal review.
If a studio never raises a change-order conversation during a build, that's a signal — either they're building the wrong thing quietly, or the cost will surface at the end.
What does a complete scope document look like?
Five plain-language sections on a single page. Here's a compressed example:
Problem. "Independent physiotherapists in the US spend 4–6 hours per week on scheduling that should take 30 minutes — phone calls, spreadsheets, and calendar tools that don't understand session types."
Users. "Two roles: therapist (manages availability, confirms or declines requests, adds session notes) and patient (requests a slot, reschedules 24h out, cancels). No separate admin role in v1."
Features. "Therapist: availability calendar, request queue, session notes. Patient: session request, reschedule, cancel. Auth for both."
Non-goals. "No mobile app. No insurance billing. No HIPAA-compliant record storage. No group sessions. No video."
Success metric. "Ten therapists paying $49/month after 60 days."
That's under 150 words. A brief like this produces comparable quotes, a clear scope-gate during the build (is this in the brief?), and a clean change-order conversation when something outside it arrives.
If you want to know what a brief like this produces in cost, what an MVP costs in 2026 has the tier breakdown. The timeline that follows from a scoped brief is in how long an MVP takes week by week. For what to check before signing with a dev shop once you have quotes in hand, 12 questions before wiring the deposit covers the contract side.
Heuristics
- One page is a constraint, not a goal. If the scope can't fit on one page, it hasn't been decided yet — it's a list of assumptions wearing a brief.
- Non-goals are scope insurance. Every item you explicitly exclude closes a conversation before it starts.
- The brief is the scope-gate. Every new request during the build gets one test: is this in the brief? If not, it gets a change order, not a late-night addition.
Written 2026-07-15 by Abhiraj Sakargaye.