MVP scope: how to decide what goes into version one

MVP scope is the smallest set of features that lets one user walk the main path from start to finish and get the result they came for. An MVP is not “the same app with fewer buttons” — it is one path closed properly instead of five broken off halfway. Below is how the cut works in practice, on one fictional example built from situations that keep coming back.

MVP, clickable prototype or concierge MVP — what is enough to start

Pick the cheapest of the three that answers the question you genuinely cannot answer yet; they cost different money because they settle different things.

• A clickable prototype is linked screens with no code and no database, built in Figma, Sketch or Adobe XD. Figma wires screens into interactive flows before anyone writes a line of code. It answers “does the user know where to tap”.
• A concierge MVP is the process run by hand instead of by code: a form, a spreadsheet and a person doing the work the system is meant to do. It answers “will anyone use this regularly”.
• An MVP is a working product with a narrow but complete scope. It answers “will this survive daily use”.

Sometimes the cheapest answer is no app at all. If the process handles a dozen or so events a week, two months of a concierge MVP gives you harder data than any code — and shows how much time it really takes.

The example: sixteen features that come to mind on day one

A first meeting produces a wish list, not a scope. A property management company looks after forty residential buildings and wants an app for reporting maintenance faults. The wish list: report a fault with a photo, pick the building and unit, request status, chat with the property manager, push notifications, email notifications, an admin panel, assigning requests to maintenance crews, a technician visit calendar, ratings after the repair, CSV export, monthly reports, SMS login, onboarding with a tutorial, a building noticeboard and an accounting integration.

Sixteen items. Most will exist one day — the problem is a list of wishes, not a path.

The second is a scope, because you can see where it ends. The first is an inventory each person on the team reads differently.

Three questions that push a feature into version two

A feature drops out of the MVP if even one of three answers is yes. Ask them of every item, in order.

1. Can this be handled manually for the first few weeks? With forty buildings, one person assigns requests to crews from the panel. That costs fifteen-odd minutes a day; the code you avoided writing costs weeks.
2. Does it cover edge cases? A fault needing a technician visit calendar is far rarer than an ordinary plumbing request. You do not automate the margin before the core.
3. Will the main path close without it? A resident reports a fault and sees its status with no chat at all. Chat does not block the path, so it waits.

If all three answers are no, the feature stays in the first release. That is the only criterion you need.

MoSCoW in practice: feature, category, decision, reason

MoSCoW splits scope into four categories — Must have, Should have, Could have and Won’t have — and only Must have goes into the MVP. The last column matters most: a category without a reason is just an opinion, and it comes back at the next meeting.

Sixteen items became six. Choosing the stack, testing and release come next — the guide on how to build a mobile app covers them, and the effect of scope on budget is broken down in mobile app development cost. One decision the cut does not settle is where the product runs at all: a web app or a mobile app follows from where the user stands when they reach for it.

Admin panel, onboarding, notifications and export — the four most common arguments

These are the features clients fight hardest for, so each gets its own rule rather than a general appeal to keeping things minimal.

An admin panel enters the MVP in minimal form whenever someone on the other side has to react: a list, a detail view and a status change. Account, role and configuration management stays with the technical team to handle by hand.

Onboarding waits almost every time. A tutorial is a prosthetic for an interface the user does not understand; better to fix the screen than write instructions for it.

Notifications stay on one channel, the cheapest to run — usually email. Push needs a mobile release, consent handling and separate infrastructure, so it is a natural second-release candidate; how long it takes to build an app depends mostly on how much you fit into the first scope. If you were hoping to skip the release and send push from the browser instead, check what progressive web apps do and do not do on iOS first, because there notifications only arrive once the user has added the app to the home screen.

Data export moves to version two for as long as you can produce a report on request. One condition: the data must be complete from day one. Missing data cannot be recovered retroactively; a missing “download” button can.

What you must never cut from an MVP

Five things stay in scope however aggressively you cut the rest, because leaving them out is not a saving but a debt: authentication, backups with a working restore, GDPR compliance, basic accessibility and error handling.

Authentication and backups make the version fit to show users at all. GDPR compliance here means a lawful basis for processing, a notice for the user and the ability to delete an account — added later it touches the data model, the most expensive part of the system. This article is informational and is not legal advice. Basic accessibility means contrast, keyboard operation and sensible field labels; error handling means a message when a photo fails to upload rather than a blank screen.

The only thing you may narrow is scope, not quality: one login method instead of three, one backup export format instead of a full console.

How to write scope so it can be ticked off

Scope is ready when every item has acceptance criteria written as questions answered only YES or NO. A question you can answer with “partly” is not an acceptance criterion.

Start with a user story in the “As a [role] I want [feature] so that [benefit]” template, then attach the questions. A good story is testable — if you cannot phrase a question that settles it, the description is too vague.

Put the stories in the order the user touches them — that is user story mapping — and cut the map with a horizontal line. Everything above it is the first release, everything below waits. Two-week sprints close that scope incrementally, and the map shows after each sprint whether the line has moved.

The same set of stories is ready-made material for a software project brief — you only need to add the business context. If you would rather have the cut sanity-checked first, tell us about the project and we will come back with a proposed scope.