MVP scope: what to build first and what to postpone

The most common first-version mistake is not a feature list that is too long. It is a list where every feature is half-finished. The result looks like a product in screenshots, but nobody can use it from start to finish, so nothing is learned from it either. A more useful definition: a first version is one workflow that a real person can complete in full, without your help and without apologies.

In short

• A first version is one complete workflow, not a draft of every feature.
• Choose a path with a clear start and finish, where the user actually gets a result.
• More can be postponed than it appears: admin screens, self-service, reports, integrations, multiple roles.
• Some parts are not "features" and cannot be postponed: sign-in, data protection, failure states, backups.
• Before you start, agree what observation would count as evidence that the direction is right. Otherwise you will be judging an impression.

How to choose that one path

The right path is usually the reason the product exists — the place where the user gets what they came for. A useful test: can you describe it in one sentence, with an action at the start and a result at the end. If the description needs three sentences and the word "also", it is probably not one path but three.

• The path has a clear starting point: the user arrives somewhere and knows what to do first.
• The path ends in a result they can see or receive — a record, a document, a confirmation.
• The path can be completed without your help, without a phone call and without editing the database from the side.
• The path still works when something goes wrong: an understandable message rather than a blank screen.
• The path is used by the role the product matters most to, not the role that is easiest to build for.

A concrete postponement list

These almost always survive being pushed to a second version, even though they look essential up front. Postponing is not abandoning — it is a decision about order.

• An admin interface. In the first weeks you can often manage the data yourself without a screen per table.
• User self-service: profile editing, photographs, notification settings.
• Reports and charts. With no data yet, a report shows an empty panel.
• Multiple roles with fine-grained permissions. Start with two, and only if you genuinely need two.
• Integrations with external systems, where an export can stand in for a while.
• Billing, if the first users are being invited personally.
• Multiple languages, if the first audience is one.
• A mobile app, if the same path works in a browser.
• Automated reminders and email sequences.
• Small settings that let people change things nobody has yet asked to change.

What cannot be postponed

Some work does not look like a feature, so it rarely makes the list. It is exactly the work that costs most later, because it has to be fitted into a product already in use. Sign-in and permission checks on the server, limiting personal data to what is genuinely needed, understandable failure messages, and backups with a restore that has actually been tried — none of these are second-version topics.

• Sign-in and permission checks on the server, not only in the interface.
• Data minimisation: do not store what you do not use.
• Failure states: what the user sees when something fails, and whether their data survives it.
• Backups plus at least one tested restore — a backup nobody has restored is an assumption.
• The basic legal items: privacy information and consent records, if you collect data.
• The ability to see what happened: at least minimal records of significant actions.

An illustrative example

Illustrative scenario, not a description of a client project. Imagine a services company that wants to take bookings online. The first version could be one whole path: the customer picks a service, leaves their contact details and receives a confirmation, while a staff member sees the booking in a list and can mark it done. That path contains no reports, no billing, no self-service and no second language. But it works end to end without help, so something can be learned from it. The alternative — a quarter of every feature — would look broader while nobody could actually use it.

Agreeing in advance what "it worked" means

This is the easiest place to fool yourself. Set the criteria after launch and almost any outcome can be narrated as success. So it helps to write down beforehand what observation would count as evidence — and what you would do in its absence. The criterion has to be yours rather than borrowed: there are no general numbers that "mean success", and any figure written here would be an assumption rather than a norm.

• What has to happen for you to treat the direction as right — name an action, not a feeling.
• Over what period you will judge it, and what will stay unchanged so the result is comparable.
• How many people have to complete the path for it not to be one lucky case.
• Where people stop — often more valuable than the overall number.
• What specifically you will change if the criterion is missed: the path, the audience, or the idea.
• Which outcome would mean the idea is not worth continuing. The hardest point, and the most useful.

What this guide does not tell you

It contains no timelines and no totals. The scope and cost of a first version follow the path you choose and the state of your existing systems, so any figure written here would be an assumption rather than an estimate. Nor is there a universal feature list: the same screen is foundational for one product and a postponement for another. Its purpose is different — to have you choose scope around one complete path rather than around what is easiest to demonstrate.

If you prepare just one thing before the conversation — a single sentence describing the path, with an action at the start and a result at the end — the scope discussion will be short, and the postponement list will almost write itself.