Guide · MVP scope

What goes into an MVP and what to leave out

A practical guide to cutting a first product down to the part that teaches you something, without cutting the parts that keep it safe.

An MVP should contain the one core flow your first users came for, done properly, plus the things that protect them and you: data safety, a working sign-in if accounts exist, and basic analytics. Admin panels, settings pages, rare edge cases and nice-to-have features wait until real usage shows they are needed. Fix the scope and the launch date in writing before building, so the product cannot quietly grow.

Start a project

Updated 2026-10-01

What an MVP is, and what it is not

A minimum viable product is the smallest version of a product that real people can use for its main purpose, so you can learn whether they want it. Two words do the work. Minimum means you leave things out on purpose. Viable means what remains actually works.

It is not a prototype. A prototype shows an idea to people in a room; an MVP is used by strangers who owe you nothing. It is not a demo for investors either, and it is not version one of everything you have planned with the rough edges left in.

The test is simple: can a stranger arrive, do the one thing the product exists for, and leave having got what they came for? If yes, it is an MVP. If they hit a dead end, it is not viable. If they wander through ten features first, it is not minimum.

Pick the one job the first version must do

Every product idea contains several jobs. A marketplace lets people sell, buy, browse, message, review and pay. Trying to launch all of them at once is how first versions end up late and mediocre at everything.

Write down, in one sentence, what a first user must be able to do for the product to be worth opening. Then ask which other jobs that sentence cannot survive without. Those stay. The rest wait.

MtLocalGoodies, a marketplace for local producers in Malta, is a clear case. Browsing by place was the core: people look for what is made in their own town. So all ninety-nine localities of Malta and Gozo were modelled first, as proper records, before the first seller arrived. A place-based marketplace that opened with half the islands missing would have failed its one job. The product then shipped on a fixed-date MVP track.

Name the user. Not “everyone”. The specific first person who will use it.
Name the job. One verb and one object: find a producer, book a slot, send an invoice.
Name the proof. What you will see in the first weeks of use that tells you it worked.

What to cut from the first version

Most of what gets cut is work that serves the team, not the user. It feels essential because the team can picture needing it. Early on, a person with a database tool and a checklist can do most of it by hand, and doing it by hand teaches you what the automated version should really be.

Admin panels. Build the screens your users see. Your team can manage records with simpler tools until the volume makes that painful.
Edge cases. Handle the paths most users take. For the rare ones, show a clear message and a way to contact you, then fix them when they turn out not to be rare.
Settings. Every option is a decision you postponed. Choose sensible defaults and let usage tell you which ones people actually want to change.
Extra roles and permissions. One kind of user, or two at most, until the product proves there are more.
Integrations. Connect to other systems when a paying user asks for it, not because a competitor lists it.
Polish on secondary screens. The core flow gets full care. The about page and the empty states can be plain.

What not to cut

Some things look optional and are not. Cut them and the MVP either hurts the people using it or teaches you nothing.

Data safety. Passwords stored properly, personal data protected, backups running. A small product that leaks data is not a small problem.
The core flow, end to end. The one job must work completely, including the moment a user finishes it. Half a checkout is not an MVP of a shop.
Basic analytics. You built the MVP to learn. Without a record of how many people arrive, start the core flow and finish it, you learn only from opinions.
A way to reach you. When something breaks for an early user, a visible contact route turns a lost user into feedback.
Speed and phones. If most of your users are on a phone, the core flow has to work well on one from the first day.

Feature by feature: first version or later

A typical split for a product with accounts. Your list will differ; the reasoning should not.

Feature	In the first version	Later	Why
Core user flow	Yes, complete	Nothing deferred	It is the reason the product exists and the only thing you are testing
Sign-in and accounts	Yes, simple	Social sign-in, teams	Needed if users return to their own data; extras can wait
Data protection and backups	Yes	Nothing deferred	Mistakes here cannot be undone after launch
Basic analytics	Yes	Detailed dashboards	Without it the MVP cannot answer the question it was built for
Admin panel	No	Yes	The team can manage early records by hand
Settings and preferences	No	When users ask	Good defaults are enough until usage shows otherwise
Rare edge cases	A clear message only	Yes	Fix the ones real users actually hit
Third-party integrations	Only if the core flow needs one	Yes	Each one adds work and a new way to fail
Notifications	Only the essential ones	Yes	A confirmation the user needs is core; a weekly digest is not

Fixed scope and a fixed date

An MVP grows in small, reasonable steps. Each addition sounds sensible on its own, and together they push the launch back until the product is no longer minimum. The defence is to write the scope and the launch date down before building starts, and to treat both as fixed.

A fixed date changes the conversation. When a new idea arrives, the question is no longer “is this good?” but “is this worth more than launching on time?”. Usually it is not, and it goes on the list for the next version. That list is not a failure. It is the roadmap, built from things you were disciplined enough to postpone.

This is how we run MVP development: a written scope and a launch date agreed before work starts, and a build that delivers exactly that.

Signs your MVP is too big

You cannot describe what it does in one sentence.
The scope has more screens for your team than for your users.
Nobody can say which single feature, if it failed, would make the product pointless.
The launch date has moved more than once and nobody outside the team has used it yet.
You are building for a user type you have never spoken to.

After launch

Launch is when the MVP starts paying for itself in information. Watch the analytics for where people stop. Talk to the first users directly; at this size you can. Then rank the postponed list against what you have learned, not against what seemed important before launch.

Expect to drop some of it. Features that felt essential in planning often turn out to be things nobody asks for, and the ones users do ask for are sometimes missing from the list entirely. That gap is exactly what the MVP was built to show you.

Keep the same discipline for the next version: one clear goal, a written scope and a date. The product grows, but it grows in steps you can measure.

Questions about MVP scope

How many features should an MVP have?

As few as the core job allows. Count the features the one main flow cannot work without, add data safety and basic analytics, and stop there. A number set in advance matters less than being able to justify each item.

Should an MVP have user accounts?

Only if users need to come back to their own data. A tool that does its job in one visit may not need sign-in at all. If accounts are needed, keep them simple and secure, and add extras later.

Is an MVP the same as a prototype?

No. A prototype shows an idea and is often not fully working. An MVP is a real product that strangers use for its main purpose, so the core flow has to work completely.

What if users ask for a feature we cut?

Good: that is the signal the MVP was built to produce. Note how many ask and why, then rank it against everything else on the postponed list.

Can an MVP be built on a fixed date?

Yes, if the scope is fixed too. A date only holds when what will be built is written down and changes go to the next version. See MVP development.

Tell us what you are building.

One project at a time, a fixed fee against a written scope, and you keep the source code and the rights. Write in English, Polish or Spanish.

Start a project hello@scorvia.studio