How to scope an MVP in one afternoon

Why it matters

A loose scope is the main reason MVPs cost more and take longer than planned. It is also the main reason quotes vary so wildly: if three developers have to guess what you mean, you get three different guesses, each with a buffer for the risk.

A good scope does not need to be long. It needs to be specific enough that someone else could build the right thing from it, and short enough that you will actually hold to it. One page, written in an afternoon, is usually enough for a first version.

This method assumes you already know the problem and roughly who has it. If you have not yet spoken to people who might use the product, do that first. No amount of scoping fixes an idea nobody wants. This is part of my guide to how to build an MVP.

You will need four hours, a notebook or a blank document, and either the MVP scoping tool open in a tab or the willingness to do the sorting by hand.

The checklist

Hour one: the first user and the one job

Most scopes go wrong in the first sentence, by describing a product for everyone. Start narrow. You can widen it later.

If you cannot fill in the one job in a single line, stop here and come back once you can. Everything after this depends on it. A good one-job line is specific enough to test. "Help vendors manage their business" is not. "Let a street food vendor publish next week's pitches in under two minutes" is, because you can watch someone try it and time them.

Hour two: the core flow

Before any features, sketch the path a first user takes from arriving to getting the job done. Boxes and arrows on paper are fine.

Keep the flow short on purpose. Every step you add is a step where a first user can give up, and every step is something to design, build and test. If the flow has more than about eight steps from arriving to the job done, look for steps that could be merged, moved later or done by you behind the scenes.

Hour three: features and the three questions

Now list features, but only ones that appear somewhere on the flow you drew. Then put each one through three questions. This is exactly what the MVP scoping tool does, so you can use it here instead of a spreadsheet.

1. 1

   Does the first user need it to get value?

   Not a user in a year. The first person who uses it.

2. 2

   Does it stop them paying you?

   If a user cannot pay without it, it is a must-have, because whether people pay is the main thing an MVP is for.

3. 3

   Could you do it by hand at first?

   An email instead of a notification system, a spreadsheet instead of an admin panel, a manual approval instead of an automated one.

If the must-have list is still long, go back to the by-hand answers. Founders often say a step cannot be done by hand because doing it by hand sounds unprofessional. For the first ten users it rarely is. What to cut from your MVP has a long list of features that can usually wait, area by area.

Hour four: the time budget and the one-page scope

The last hour turns your notes into something you can hand to a developer.

The time budget idea comes from Basecamp's Shape Up method, which calls it the appetite: the amount of time you are willing to spend on an idea, set before any design starts. An estimate starts with a design and produces a number. An appetite starts with a number and shapes the design to fit. For an MVP that is the right way round, because the point is to learn quickly, not to finish a list.

What the page looks like

Here is an invented example, to show the level of detail that is enough. It is not a real client.

Section	Example
First user	A yoga teacher who runs three classes a week and takes bookings by text message
One job	Let students book and pay for a class spot from a link
Core flow	Open link, pick a class, pay, get a confirmation email
Must-haves	Class list, booking, Stripe payment, confirmation email, teacher sign-in
Should-haves	Waiting list, done by hand at first
Cut list	Class packs, student accounts, reminders, native app, reviews
Time budget	Four weeks
Success	Ten paid bookings from students who are not friends, in the first month
Open questions	Refund rules for cancelled classes

That fits on one page, and a developer could give you a firm quote from it.

Common misses

Scoping for the second user. Admin roles, team accounts and enterprise features creep in because someone imagined a customer you do not have yet. Scope for the first one.

Leaving out the invisible work. Sign-in, permissions, email sending, payments webhooks, error handling and the legal pages are not features users ask for, but they take real time. A scope that skips them produces a quote that misses them.

Writing features, not outcomes. "Dashboard" tells a developer nothing. "A vendor sees their next three bookings and can cancel one" tells them what to build and when it is done.

No cut list. If the things you decided not to build only live in your head, they come back mid-build as change requests. Write them down and share them.

No date that matters. A pitch, a pilot customer, a launch event. Without a real date the time budget is a wish.

Skipping the conversation with users. The afternoon gives you a scope. It does not tell you whether the problem is real.

Next step

Take the must-have list and put it through the MVP cost calculator. It gives a price range and a rough number of weeks for building it yourself with AI tools, with me, or with a typical UK agency. How long it takes to build an MVP explains where those weeks go, and what an MVP costs in the UK explains the price.

When you are ready to talk to developers, take the one-page summary with you and use the questions to ask before hiring an MVP developer. If the idea is still loose after the afternoon, that is what my Validation Sprint is for: 1 to 2 weeks, from £3,500, ending in a clickable prototype, a build plan and a fixed quote. It is on the pricing section of the home page.