How to scope an MVP: what to build first, and what to leave out

If you're a founder with a product idea, you probably have a long list of features in your head already. You can see the dashboard, the settings page, the mobile app, the integrations. The trouble is that building all of it before anyone has used it takes time and budget you'd rather spend learning whether the idea works.

That's what an MVP is for. A minimum viable product is the smallest version of your product that proves the idea and works for real users. Scoping it means deciding what that version contains, and just as importantly, what it leaves out for now. Get the scope right and a first version becomes very achievable. A typical MVP takes us 2–4 weeks from start to launch, and almost all of that speed comes from good scoping.

Start with the one thing you need to prove

Every product idea rests on an assumption about people. Before you list a single feature, write that assumption down as one sentence: who will do what, and why. For example, "Small clinics will book appointments online because phone booking takes up their front-desk time." Your sentence will be different, but it should be that specific.

That sentence is what your MVP has to test. Every feature you consider from here on should help prove it or disprove it. If a feature doesn't touch the assumption, it can probably wait.

Map the journey, not the feature list

Feature lists grow because they're easy to add to. A journey is harder to pad. Walk through what one person does, step by step, from the moment they arrive to the moment they get value from your product.

1. How do they find you and sign up?
2. What's the first thing they need to do?
3. What's the moment they get what they came for?
4. What would bring them back a second time?

Only the steps on that path are candidates for your first version. Everything else, however useful it sounds, belongs on a later list.

Sort every feature into three piles

Now take your feature list and sort each item honestly.

• Must have. Without it, the core journey breaks. A user can't get from arriving to getting value.
• Nice to have. It makes the experience better, but the journey still works without it.
• Later. It only matters once you have users, such as detailed analytics, advanced settings, or features for teams you don't have yet.

Your MVP is the first pile. If the first pile feels too big, it usually is, and the next section helps you trim it.

Questions that help you cut

• Would your first users notice it was missing?
• Could you handle it by hand for the first few users while you learn what they really need?
• Does it help prove the assumption you wrote down?
• Is it on the list because a competitor has it, or because your users need it?

Doing things by hand early on is underrated. If ten users need a weekly report, you can put it together yourself for a month before deciding it's worth building. You'll also learn exactly what the report should say.

What usually waits for version two

• Several user roles and permission levels, when one role is enough to prove the idea.
• Settings and customisation options before anyone has asked for them.
• Building for scale you don't have yet.
• Launching on every platform at once. Start where your users already are.
• Integrations with tools your first users may not even use.

None of these are bad ideas. They're just better ideas once real users have told you which ones matter.

A worked example

Let's run the clinic idea from earlier through the whole process. It's an imaginary product, but the thinking is the same for any idea.

The assumption: small clinics will book appointments online because phone booking takes up their front-desk time. The journey for a patient is short. They open a link from the clinic, pick a time, enter their details and get a confirmation. The journey for the clinic is just as short. They set their available hours and see the bookings come in.

The first feature list probably had twenty items on it: reminders by text, online payments, patient histories, a mobile app, staff accounts, reviews, a calendar sync, reports. After sorting, the must-have pile is small:

• A booking page each clinic can share.
• A simple way for the clinic to set its available hours.
• A confirmation for the patient and a list of bookings for the clinic.

Reminders could be sent by hand for the first few clinics. Payments, histories and the mobile app all wait until clinics are actually using the bookings. That's a first version you can build quickly, put in front of real clinics, and learn from. If clinics use it, the next things to build will be obvious, because they'll tell you.

Decide what you'll learn after launch

An MVP is a starting point. Before you launch, decide what you want to find out. Do people sign up? Do they finish the core journey? What do they ask for that isn't there yet? Write these questions down, because they'll shape your second version far better than the original feature list will.

Plan for that second version too. The best first versions are built so they can keep improving, rather than being thrown away once they've done their job.

How we scope MVPs at Qodenova

Scoping happens in the first two stages of our process. In Understand, we talk through your idea, your goals and your constraints. In Plan, we define the scope, prioritise features and choose the technology that fits, all before development begins. You leave with a clear roadmap and a first version you can actually picture.

From there we design the experience, build it, test it with you, and support you through launch. Pricing is flexible and shaped around your needs, and once the project is paid in full, the code, designs and content are yours.

Want a second pair of eyes on your scope? See how our MVP development works, read more about how we work with founders, or tell us about your idea.