How to scope an MVP

To scope an MVP, pick the one job your product must do for one specific type of user, list everything needed for that job to work from start to finish, and move everything else to "later". A minimum viable product is the smallest version that real people can use for real, so you can learn whether the idea works. It isn't a demo, and it isn't version one of everything you plan to build. Most of scoping is saying no, in writing, to good ideas.

Start with one core job

Write one sentence: "[This user] can [do this job] without [the current pain]." For example, "A clinic receptionist can confirm tomorrow's appointments without phoning each patient." Or, "A small importer can see where each shipment is without chasing three suppliers on WhatsApp."

If you can't write that sentence, you're not ready to scope. If you've written three, choose one. Products that need two kinds of user from day one, such as a marketplace's buyers and sellers, have to scope both sides, so keep each side as thin as you can.

Be specific about the user, too. "Small businesses" isn't a user. "Owners of clinics with two or three branches who do their own admin" is. The narrower the user, the easier it is to say no to features, and the easier it is to find the right people to test with.

The core job tells you who to design for, which flows are essential and what success looks like. Every feature request after that gets the same question: does the core job fail without it?

What "viable" actually means

"Minimum" gets most of the attention, but "viable" is the harder word. A viable product:

• Lets the user finish the core job from start to finish. Some steps can be done by hand behind the scenes, but the user shouldn't hit a dead end.
• Works reliably enough that people trust it with their real data, money or time.
• Is clear enough that a new user understands it without a guided tour.
• Meets the non-negotiables for your field: security for payments, privacy for health data, and basic accessibility for everyone.

A product that skips these isn't lean. It just teaches you the wrong lesson, because people leave for reasons that have nothing to do with your idea.

Cutting features without cutting the point

List every feature anyone has suggested. Then go through them with these questions:

• Does the core job fail without it? If not, it can probably wait.
• Can it be done by hand for now? Approvals, reports and onboarding are often fine as manual work for your first users.
• Can an existing tool do it? A spreadsheet, a form builder, a shared inbox or an off-the-shelf service often covers back-office needs early on.
• Is it for users, or for the pitch deck? Investors like to see a roadmap. They don't need it built.
• Would we notice if nobody used it? If you can't measure it, you can't learn from it.

Things that can usually wait: more than one way to log in, detailed profiles, in-app chat, multiple languages (unless your market needs them from day one), advanced filters, dashboards for numbers you don't have yet, and a polished admin panel.

A must, should, later table

Put the result in a simple table that everyone signs off on. Here's an example for a hypothetical appointment reminder product:

The "must" column should feel uncomfortably short. If everything is a must, nothing has been decided.

Prototype before you write code

A clickable prototype is the cheapest place to find out your scope is wrong. Design the core flow in a tool such as Figma, put it in front of five or six people who match your target user, and ask them to complete the job. Watch where they hesitate, what they expect to find, and what they skip.

You'll often find a "must" that nobody needed and a missing step that everybody looked for. Changing a prototype takes hours. Changing a built product takes weeks. That's why our product and UX design work usually starts here.

How long an MVP takes

Timelines depend on the scope, not the label. As a rough guide, discovery and prototyping often take a few weeks, and building a focused MVP usually takes a few months. Payments, several user types or complex integrations push it out further. If the estimate for your MVP runs to a year or more, the scope probably isn't minimum yet. For what drives the size of a build, see our guide to what an app costs.

What to measure after launch

Decide before launch what you'll measure, and what result would make you change course. Useful measures for most MVPs:

• Activation: how many new users complete the core job for the first time.
• Retention: how many come back and do it again in the following weeks. This tells you far more than sign-ups.
• Time to value: how long a new user takes to get the result they came for.
• Drop-off: the step in the core flow where most people stop.
• What users say: talk to a few active users and a few who left, every couple of weeks.

Set up analytics events for the core flow before launch. Adding them afterwards means losing the first weeks of data, which are often the most useful.

Common traps

• Scope creep during the build. New ideas go on the "later" list, not into the current sprint.
• Building for scale too early. Choose a sensible architecture, but you don't need to handle a million users before you have a hundred.
• Polishing the wrong things. Animations and custom illustrations can wait. Clear wording and an obvious next step can't.
• Launching to nobody. Line up your first users before launch: a waiting list, a pilot customer, a community you already belong to.
• Treating the MVP as finished. Keep time and budget for the changes your first users will ask for.
• Skipping the boring essentials. Backups, password resets, error tracking and a privacy policy are part of "viable".

If you have an idea and a long feature list, we can help turn it into a scope you can build and test. Contact us for a quote.

Questions people ask

What's the difference between an MVP, a prototype and a proof of concept?

A proof of concept tests whether something is technically possible. A prototype shows how the product would look and work, usually without real data. An MVP is a working product that real users use for real, so you can learn whether they value it.

Should an MVP be a mobile app or a web app?

Often a web app first, because it's quicker to change and easier to share. Choose a mobile app when the core job depends on the phone, such as the camera, location, notifications or offline use.

Can an MVP be built with no-code tools?

Sometimes, yes. No-code tools can work well for simple workflows and early tests. They become limiting with complex logic, payments, performance needs or strict data rules, so check where you'd hit those limits before committing.

How many features should an MVP have?

There's no right number. It should have every feature the core job needs to work from start to finish, and as few others as possible.