Guide · Scoping
What an MVP actually needs in week one
An MVP is not a small version of everything — it's the smallest thing that
lets a real user complete the one workflow that proves your idea. Week one
is where that gets decided. Here's what genuinely matters, and what to cut.
Needs: one workflow, end to end
- The core loop, complete. If it's a booking tool: pick a slot → confirm → both sides see it. Every step real, none mocked. A partial loop teaches you nothing, because users bounce at the gap.
- Just enough data. Real records in a real database — even if you enter them by hand. Fake-looking seed data makes every test session feel dishonest and hides real edge cases.
- The honest paths. Empty states, error states, and the "what happens when there's nothing here yet" screens. These are where MVPs feel real or fake, and they're cheap to build when scoped early.
- A way to see who did what. Even a simple activity log. You can't learn from week one if you can't see what users actually did.
Cuts: what can wait for week two and later
- Roles and permissions beyond user/admin. Multi-role systems expand scope faster than any other feature. One admin account covers validation.
- Polish that isn't load-bearing. Animations, themes, settings pages, profile customization — none of it validates the idea.
- Integrations "because users will expect them." Prove the workflow first; wire the calendar sync after people are using the workflow.
- Scale. One honest user completing the loop beats infrastructure for a thousand imaginary ones.
The test
Write the workflow as five to seven numbered steps. If you can't, the scope
isn't clear enough to build — and no sprint will fix that. If you can, count
the screens: an MVP in week one is usually six to ten screens. Twenty screens
in week one almost always means the "M" has crept.
Guide · Process
How to scope a sprint so it doesn't fail
Fixed-scope sprints fail in one of two ways: the scope was never actually
fixed, or it was "fixed" around features nobody needs. Both are scoping
failures, and both are avoidable before day one.
Freeze the outcome, not the feature list
A sprint scope should read like a demo script: "A coach signs up, creates a
session, shares a link, a client books and pays a deposit, both get an email."
Not a checklist of 40 features. When you argue in week two — and you will —
the demo script settles it; a feature checklist just grows.
Put the riskiest part first
The thing most likely to break the sprint — the AI step, the payment
integration, the weird data format — belongs on day one or two, not day four.
If the risky part can't work in five days, you want to know on day two, with
four days left to re-scope, not on day four with none.
Agree on what "done" means per feature
"Payments work" is a scope argument waiting to happen. "A client can pay a
deposit with a test card and the owner sees the record" is checkable. Write
one testable sentence per feature before the sprint starts; ambiguous
acceptance criteria are where fixed scope quietly dissolves.
Write the not-list
Equal in importance to the feature list: an explicit list of what this sprint
will not include. Multi-tenant workspaces, mobile apps, CSV export,
whatever it is — naming it now converts a week-three disappointment into a
day-zero decision.
Plan the freeze conversation
Decide upfront how mid-sprint ideas are handled: captured in a list, reviewed
after handoff, and swapped only if something of equal size comes out. A sprint
without a change policy doesn't have fixed scope — it has fixed scope until
the first good idea arrives.
Guide · Judgment
Five signals your MVP scope is right-sized
Before committing to any build — sprint or otherwise — check your scope
against these five signals. They take ten minutes and catch most
over-scoped MVPs.
1. You can demo the whole thing in five minutes
Walk through the workflow out loud, no slides. If the demo takes much longer
than five minutes, either the loop is too big or you don't actually know what
the product does yet.
2. Removing any feature breaks the story
In a right-sized MVP, every feature is load-bearing: take one out and the
demo stops making sense. If you can remove a feature and the story still
works, it was never part of the MVP.
3. The data model fits on one page
Users, one or two core records, maybe a join. If the schema diagram needs a
second page, you're building the version-two product and calling it version
one.
4. You know whose problem it solves, by name
Not a market segment — an actual person you'll put in front of it the day it
ships. "Validating demand" with no named first user is how MVPs get built
that nobody needed.
5. The rule-set is written down
Especially for compliance-adjacent tools: the checks, thresholds, or content
rules the software enforces exist as a document before development starts.
If the rules only exist in someone's head, the sprint will spend its days
extracting them instead of implementing them.