To scope an MVP, fit it on a single page. Name the one core user loop your product has to prove, list only the must-have features that serve that loop, write down everything you are deliberately cutting, and pick one success metric. If it does not fit on a page, it is too big. That one constraint kills scope creep before it starts.
Most MVPs fail not because the idea was wrong but because the scope was never bounded. "Minimum" quietly becomes "everything we can think of," the timeline triples, and the budget is gone before a single user gives feedback. The one-page method exists to stop exactly that. Here is how to run it.
Why should an MVP fit on one page?
Because a page is a forcing function. You cannot hide a bloated feature list on a single sheet — the moment it overflows, you are looking at proof that the scope is too large. The constraint does the arguing for you.
It also creates a shared source of truth. When your team, your designer, and your developers all point at the same page, "is this in the MVP?" has a written answer instead of a debate. A one-pager is not a lightweight version of a spec. For an MVP, it is the spec.
Part 1 — Define the single core user loop
Every product has one loop that delivers its core value — the sequence a user repeats to get the thing they came for. Nail this and everything else is optional. Blur it and no amount of features will save you.
State it as a short cycle. For a food-delivery app: open app → browse restaurants → place order → track delivery → reorder. For a marketplace: list an item → get discovered → message → transact. Write your loop in one line. If you cannot, you do not yet understand the product well enough to build it — and that clarity is worth more than any feature.
Part 2 — Separate must-have from nice-to-have
With the loop defined, sort every feature you have imagined into two columns. The test is brutally simple: does this feature make the core loop work?
- Must-have — the loop physically cannot run without it. In a marketplace, listing and messaging are must-haves; without them there is no product.
- Nice-to-have — it improves the experience but the loop runs fine without it. Ratings, saved searches, dark mode, referral bonuses, in-app wallets. All good ideas. None of them belong in v1.
Founders overload the must-have column because every feature feels essential. It is not. If a user can complete the core loop without it, it is a nice-to-have — move it. Be ruthless here; this column decides your timeline and your cost more than any technical choice.
Part 3 — Write the cut list on purpose
This is the step most teams skip, and it is the most important. Take everything you moved out of must-have and write it down as an explicit cut list — a visible record of what you are deliberately not building yet.
The cut list does two jobs. It reassures everyone that good ideas are not lost, only postponed — which makes cutting far easier emotionally. And it becomes your defence against scope creep: when someone lobbies to add a feature mid-build, you point at the list and ask whether it beats everything else already parked there. Written down, a cut feature is a decision. Left unwritten, it comes back every week as a fresh "quick request."
Part 4 — Pick one success metric
An MVP is an experiment, and an experiment needs a result you can read. Choose one number that tells you whether the core loop actually works for real people.
Make it a metric of genuine usage, not vanity. Not downloads — those measure your launch, not your product. Reach for something like: 40% of new users complete the core loop in week one, or 20 users place a second order, or ten paying customers in the first month. One metric, written on the page, agreed before you build. It is the difference between "did people use it?" and a yes-or-no you can act on.
What does the one-page scope look like?
Put it all on a single sheet in this shape, and fill each line in one or two sentences:
- Problem — the one problem this MVP solves, in a sentence.
- Core user loop — the repeating cycle that delivers the value, as a short arrow chain.
- Must-have features — the short list that makes the loop run. Aim for three to five.
- Cut list — everything you are deliberately not building yet.
- Success metric — the single number that defines whether it worked.
- First ten users — exactly who you will put this in front of, by name or segment.
That is the whole document. If you cannot fill it in, you are not ready to build. If it spills past a page, you are not scoping an MVP — you are scoping a product.
What does a filled-in one-pager look like?
Take a home-services booking app. On one page it reads: Problem — people cannot find a trusted plumber fast. Core loop — search a service, pick a pro, book a slot, pay, rate. Must-haves — search, provider profiles, booking, payment. Cut list — in-app chat, subscriptions, loyalty points, provider analytics, multi-city support. Success metric — 25 completed bookings in the first month. First ten users — neighbours in one area who need a plumber this month.
Notice how much lives on the cut list, and how little is actually required to test whether people will book and pay. That imbalance is not a mistake — it is the method working exactly as intended.
How do you actually say no to scope creep?
Scope creep does not arrive as one big decision. It arrives as a dozen reasonable-sounding "while we're at it" requests, each small, each adding a few days. Together they sink the timeline. The one-pager is your shield:
- Route every new idea to the cut list, not the build. The default answer during a build is "after v1," not "sure."
- Make additions compete. A feature only enters the MVP if it beats something already in the must-have list — and then something else has to leave.
- Tie every request back to the loop and the metric. If it does not help prove the core loop or move the success metric, it waits.
Saying no is not rigidity; it is protecting the experiment. Every yes spends runway you will want after launch, when real users tell you what to build next.
What happens after the one page?
The one-pager is the scope; the next step is turning it into shipped software fast. A tightly scoped MVP built this way is exactly what a focused six-week build is designed to deliver — design the critical path, ship weekly, and put it in front of your first ten users. We walk through that process in How to Build an MVP in 6 Weeks.
The scoping is the hard part, and it is where founders save the most money. Get the one page right and the build almost scopes itself.
If you want help turning your idea into a one-page scope — with the features honestly cut, not padded — tell us what you're building and we'll map it to a real loop, a real metric, and a real timeline.