What is an MVP? What to include and what to leave out

What is an MVP? It is the smallest version of your product that lets real people do one useful thing, so you can learn whether they want it. It is not a demo, and it is not version one of everything you plan to build. Most of the work is deciding what stays out.

What is an MVP, in plain terms

MVP stands for minimum viable product. Each word carries weight.

• Minimum means you build less than you want to. Far less.
• Viable means it still works. A user can finish the job it promises without help from you.
• Product means people use it in real conditions, not in a meeting room while you narrate.

The goal is learning, not revenue and not applause. An MVP answers a question you cannot answer by thinking harder: will people use this, and will they come back?

A useful test is to write the question down before you build anything. “Will freelancers upload receipts every week if the app sorts them for tax?” is a question. “Will people like our app?” is not. If you cannot name the question, you are not ready to define the MVP yet.

What an MVP is not

Founders often confuse the MVP with three other things. Each one costs time in a different way.

Often called an MVP	What it actually is	Why it falls short
A clickable prototype	A design that looks real	Nobody can use it for real work, so you learn about opinions, not behavior
A beta of the full product	Every planned feature, half finished	It takes months, and nothing is good enough to judge
A landing page with a waitlist	A test of interest	Useful before an MVP, but sign-ups do not tell you about retention
A cheap first version	The full scope, built fast	Low quality hides whether the idea or the build is the problem

A prototype and a waitlist page are good tools. Use them first if you can. They are steps before the MVP, not replacements for it. If you want a full method for that earlier stage, read how to validate an app idea.

What to include in an MVP

Start from one user and one job. Then include only what that person needs to finish the job from start to end.

One core journey, end to end

Pick the single path that delivers the value. For a booking app, that might be: find a slot, book it, get a confirmation. Every screen on that path must work properly. Screens off the path can wait.

The minimum around the journey

Some things are not the product but still have to exist for the product to be viable:

1. Sign-up and sign-in, kept as short as possible. Email or a single social login is usually enough.
2. Basic settings, only the ones that block the journey without them.
3. Error and empty states. A blank screen on first launch loses people faster than a missing feature.
4. A way to measure. Simple analytics on the core journey, so you can see where people drop off.
5. A way to hear from users. A feedback link or a support email is fine.

Enough quality to trust the results

Minimum is about scope, not quality. If the app crashes, you cannot tell whether people left because of the idea or because of the crash. Build fewer things, and build them properly.

What to leave out of an MVP

This is the harder list. Everything here is reasonable. It just does not belong in the first release.

• Second and third user types. If your product has buyers and sellers, consider serving one side by hand at first.
• Admin dashboards. A spreadsheet or a database view can run the back office for the first few hundred users.
• Payments, if they are not the question. If you are testing whether people use the product, an invoice or a manual charge can wait. If you are testing whether people pay, then payments belong in.
• Custom settings and themes. Pick good defaults instead.
• Integrations beyond the one or two the core journey needs.
• Scale work for traffic you do not have yet. Build clean code that can grow, but do not tune for a million users on day one.

Everything you cut before the build is something you never have to debug, support, or explain.

Write the “not now” list down and share it. It stops the same features from creeping back in every week. If the hard part is ranking the cuts, our guide to MVP feature prioritization walks through MoSCoW, RICE, and the one-journey rule.

How to tell the MVP is ready

An MVP is ready when a stranger can finish the core journey without you in the room. That is the bar. Run this short check before launch:

• A new user completes the main task on a real device, unaided.
• You can see in your analytics where each user stopped.
• The app handles no data, bad data, and a lost connection without breaking.
• You know which number you will look at after two weeks, and what result would change your plan.

If all four are true, ship it. Polishing past this point mostly delays the moment you start learning.

How long and how much

Scope drives both. A focused MVP with one core journey and one user type is usually a matter of weeks, not quarters. Adding a second platform, a second user type, or a hard integration moves the number more than anything else.

At Batriders we run a fixed two-week project for new products called 2Sprint. It covers a business plan, design, build, QA, and store prep in 14 days, starting at $5,000, and the first three days are spent deciding exactly what the first release will and will not do. For a wider view of budgets, see how much does an MVP cost.

Frequently asked questions

What is an MVP in software development?

It is the smallest working release of a software product that real users can use for one real task. Its job is to show whether the idea holds up, using behavior rather than opinions.

Is an MVP the same as a prototype?

No. A prototype shows how a product could look and feel. An MVP is a working product that people use with their own data and their own time. You can learn a lot from a prototype, but you cannot learn retention from it.

How many features should an MVP have?

As few as it takes to complete one core journey. For many products that is three to five features plus sign-in. If your list runs to twenty, you are describing version two.

What happens after the MVP?

You read the data, talk to the users who stayed and the ones who left, and decide whether to improve, change direction, or stop. The MVP is the start of the product, not a finished project.

The best MVP is the one that answers your question quickly, even when the answer is not the one you hoped for.