What to put in your MVP (and what to leave out)

An MVP should contain the one core flow that proves your idea works, plus the minimum around it that lets real people use it: signup, that core flow, a way to pay if you're charging, and a basic admin view for you. Everything else waits until real users ask for it. In practice that usually means cutting half to two thirds of the features on your first list, which is also what gets most MVPs to launch in 6 to 12 weeks instead of 6 months.

Cutting features is painful because every one of them feels important. Here's a method that makes the cuts easier, and a list of what almost always belongs in version two.

What an MVP is for

MVP stands for minimum viable product. The word that matters is viable. It isn't a demo, and it isn't a broken prototype. It's the smallest version of your product that a real customer can use to get a real result.

Its job is to answer one question: will people use this, and pay for it? Every feature you add before you know the answer is a bet placed without information. Some bets will pay off. Many won't, and they'll have cost you months.

A useful test for any feature: if it disappeared, would a customer still get the core result? If yes, it's a candidate for later.

Find your one core flow

Write down, in one sentence, what a customer gets from your product. For example:

• "A clinic can let patients book appointments online without phone calls."

• "A freelancer can send a professional invoice and get paid by card."

• "A school can share notes and announcements with a batch of students in one place."

Now list the steps a customer takes to get that result, from the first screen to the moment they have it. That list is your core flow. For the invoice example: sign up, add business details, create an invoice, send it, client pays, freelancer sees it paid.

Everything on that path belongs in the MVP. Build it well, because this is what people judge you on.

What else every MVP needs

A few things sit outside the core flow but are still required for real use:

• Account and login. Keep it simple: email and password, or one social login. Add more options later.

• Payments, if you're charging. Charging from day one is the strongest signal you'll get. Use a hosted checkout from Stripe or Razorpay, not a custom billing system.

• A basic admin view. You'll need to see users, fix data and help people. A plain internal screen is fine.

• Error tracking and analytics. You need to know what breaks and where people drop off.

• Legal basics: terms, a privacy policy, and consent handled properly if you have users in India or Europe.

That's it. It feels too small. It's meant to.

What to leave for version two

These features show up on almost every first list, and almost none of them decide whether an MVP succeeds:

• Multiple user roles and detailed permissions beyond "user" and "admin"

• Team accounts and invitations, unless teams are the whole point

• Native mobile apps, when a responsive web app would work on phones

• Dashboards full of charts

• Integrations with every tool a customer might use

• Notification preferences, themes and profile customisation

• Referral programmes, loyalty points and gamification

• An AI feature added because competitors have one

Each of these might become important. Build it when a paying customer asks for it, and you'll build the version they actually want.

A simple way to make the cuts

Put every feature on a card, or a row in a spreadsheet. For each, write two scores from 1 to 5: how much it matters to the core result, and how much effort it takes.

Then sort them into three groups:

• Must have: high importance to the core flow. These go in regardless of effort.

• Later: low importance, whatever the effort. These go on the version two list.

• Discuss: high importance but high effort. Look for a cheaper version. Often a manual process behind the scenes can stand in for a feature at launch. A founder sending a weekly report by hand for the first 20 customers is fine.

That last trick is underrated. Manual work that doesn't scale is perfectly acceptable at MVP stage, and it teaches you exactly what to automate later.

How MVP scope affects cost and time

Scope is the biggest lever on both. A focused SaaS MVP built by a small senior team typically takes 6 to 16 weeks, and our guide to SaaS MVP development cost breaks down the price ranges. Adding "just a few more features" is the most common reason those numbers double.

We run every SaaS build through this kind of cut before we quote. It regularly takes a quarter to half off the first estimate, and the product launches with the part customers care about done properly.

Signs your MVP is too big

Watch for these while you plan:

• The feature list has more than 15 to 20 items for a first version.

• You can't explain the core flow in one sentence.

• Launch keeps slipping because "it's not ready yet".

• You're building for five customer types at once.

• The budget is fully spent before a single customer has used it.

If you recognise two or more, cut again. Launching something small and learning from it will teach you more than another month of building.

Questions about MVP features

How many features should an MVP have?

As few as it takes to deliver the core result. For most products that's the core flow plus login, payments and a basic admin, often 5 to 15 features in total. The count matters less than whether each one supports the core result.

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

A responsive web app for most B2B and many consumer products. It's faster and cheaper to build and change. Choose native apps first only if the product depends on phone features like background location or offline use.

Is it okay to launch an MVP with manual processes behind it?

Yes, and it's often smart. Handling some steps by hand for your first customers saves build time and shows you which steps are worth automating once you have more users.

When should I add features after launch?

When several paying customers ask for the same thing, or when you see in your data that users drop off at a step a feature would fix. Build for evidence, not for the loudest opinion.

Get your MVP scoped

Send us your feature list, however long it is. We'll help you find the core flow, cut the rest into a sensible version two, and give you a fixed price for the first release.