How to scope an MVP: build the smallest thing that proves the idea, then grow it

Start before the MVP: understand, then prototype

The UK government's Service Manual, written for teams building public digital services, describes phases that work just as well for a small business product. In discovery, you learn about your users and what they are trying to achieve, and the constraints you work within; the manual is explicit that you should not start building in discovery, and that ending discovery without going further is not a failure if the research shows it is not worth it.

In alpha, you try out different solutions to the problems found in discovery, concentrating on the areas you think will be most challenging. The manual advises building things just complex enough to test ideas, not production-quality code, and expecting to throw away code and many ideas at the end. Only then, in beta, do you take the best idea and start building it for real, first with a limited group of users, then openly.

The scoping worksheet

1. The user: one type of user to serve first, described in a sentence.
2. The job: the one thing they must be able to do, end to end, for the product to be useful.
3. The steps: the shortest path through that job, screen by screen or message by message.
4. The riskiest assumption: what must be true for this to work (people will pay, data exists, a partner API allows it), and how the prototype tested it.
5. The success signal: what you will measure in the first weeks to decide what comes next.
6. The “not now” list: everything explicitly left out, written down so it stops coming back.
7. The constraints: data protection, payments, legal requirements that cannot wait for version two.

What usually belongs in version one

• Sign-in, if users have their own data.
• The one core job, done properly, including the unhappy paths (errors, cancellations).
• Payments, if charging is part of what you are testing.
• Basic admin: a way for your team to see and correct data without a developer.
• Measurement of the success signal.
• Separate dev, UAT and prod environments, backups and monitoring, because a first version still holds real data.

What usually does not

Leaving something out of version one is a decision, not a failure. The “not now” list is the start of your roadmap, ordered by what real users ask for.

• Every user type at once.
• Native iOS and Android apps, when a responsive web app that can be installed on a phone does the job for a first version.
• Complex roles and permissions beyond what the first users need.
• Integrations with tools the first users do not use.
• Reporting dashboards beyond the success signal.
• Polishing screens nobody has used yet.

Red flags in an MVP scope

• The scope document lists features but never names the user or the job.
• Nobody can say what result would make you stop or change direction.
• The riskiest assumption has not been tested before building.
• Version one has to be perfect because it will be shown to everyone on day one.
• There is no plan for data, backups or who supports users after launch.

How we run MVP projects at Takat

We work in the same stages: understand the process, prototype the risky part, build the smallest real version, then put it live with dev, UAT and prod environments, a preview address per branch, builds on GitHub Actions, health checks and daily snapshots. Our developers use AI coding agents under review, and people merge every change. Platforms we have built and run in production include a management SaaS for training organisations in France and a booking and customer platform for a restaurant group that migrated its customer base from a previous tool. We build responsive web apps that can be installed on a phone; we have not yet shipped a native iOS or Android app. See MVP and prototypes and the MVP launch pack.