How to scope an MVP: what to build first and what to cut

What an MVP is for

A minimum viable product is the smallest version of your idea that real users can use, so you can learn whether they want it before spending more. A clickable prototype tests whether people understand the idea; an MVP has to be usable, because it tests whether they come back.

That means an MVP has to work end to end. A beautiful sign-up flow with nothing behind it is not an MVP. A plain app that lets one kind of user complete one useful job from start to finish is.

Step 1: write the one job

Write one sentence: "A [user] opens the app to [do this], and it is done when [outcome]." For example: "A customer opens the app to book a cleaning slot, and it is done when they get a confirmation." If you need more than one sentence, pick the one that makes money or saves the most time, and put the others on the later list.

Step 2: list the screens that finish that job

Walk through the job step by step and write down every screen it touches. For the booking example: welcome, sign in, choose a service, choose a time, confirm, booking details, my bookings. That is seven screens, which fits comfortably inside a 10-screen Launch package.

Then ask for each screen: can the user finish the job without it? If yes, it moves to the later list.

Step 3: cut by role

Roles multiply scope faster than features. A customer app, a staff app and an admin dashboard are three products. For a first version, ask whether one of those roles can be handled by an existing tool or by you.

• Staff can often start with a shared spreadsheet, email notifications or a simple web page.
• An admin dashboard can start as a database tool for the founder before it becomes a polished product.
• Payments can start as payment links or pay-on-arrival before they are built into the app.

Step 4: decide what can be done by hand

Many features that sound essential can be done manually for the first hundred users: approving accounts, assigning jobs, sending reminders, writing reports. Doing them by hand is slower, but it teaches you how the process should really work, which makes the eventual automated version better and cheaper to build.

Things worth building properly from the start

A few things are still much cheaper to get right in version one than to fix later.

• Data structure: how users, orders or bookings are stored, so version two does not need a migration.
• Login and security: accounts, password resets and permissions.
• Account deletion and a privacy policy, which the app stores require.
• Analytics on the one job, so you can see whether people complete it.

Keep the version-two list

Everything you cut goes on a written list, in order. It stops the same ideas being argued about every week, and when you are ready for the next version it is already half scoped. It is also a much better brief for the next quote than starting again from memory.

If you would like a second opinion on your scope, send me the one-sentence job and your feature list. I will tell you what I would build first, which package it fits, and what I would leave for later.