What Should Be in Your MVP (and What to Leave Out)?

An MVP includes only the one thing that proves people want the product. Everything that is nice but is not proof of demand gets left for later, deliberately, in writing.

Most advice tells founders to build three to five core features, which sounds useful and settles nothing. Every founder believes their five are the essential five. The argument is never about the number. It is about which ones, and nobody supplies a way to decide.

So here is the test we use, and the list of things that get built almost every time and are almost never proof.

What is an MVP actually for?

It is not a small version of the finished product. It is an experiment with a user interface.

Your product rests on one assumption that, if wrong, makes everything else pointless. Usually that assumption is that a specific group of people has a problem painful enough to change their behavior and pay to fix it. The MVP exists to test that assumption with real people and real stakes, and nothing else.

That reframing settles most feature arguments before they start. A feature is not in or out because it is important. It is in or out because it is required for the proof.

The test: does this feature carry the proof?

Take your feature list and ask three questions of every line.

One. Without this, can a real user still complete the whole outcome they came for? If yes, it waits. Not forever, just not now.

Two. Does this exist because a user needs it, or because a system usually has it? Accounts, settings, dashboards, and admin panels are usually the second. They feel obligatory because every finished product has them.

Three. Could a person do this by hand for the first fifty customers? If yes, do it by hand. Manual work at launch is not a compromise. It is the cheapest research you will ever run, because you find out exactly which parts actually need automating rather than guessing.

Anything that survives all three questions is your MVP. It is usually smaller than the founder expected and larger than the "just launch anything" crowd suggests.

What almost always gets built and almost never proves anything

User accounts and profiles, when the value could be delivered without a login. Settings and preferences pages. Admin dashboards, before there is anything to administer. Roles and permissions, when there is one type of user. Notifications the user never asked for. Onboarding tours for a product with one screen. In app chat. Social features, ratings, and gamification. Multiple platforms, when one would prove the point. Integrations with tools your first fifty customers may not even use.

None of these are wrong. They are simply not evidence, and every one of them costs the time you need for the thing that is.

What must be in even though it proves nothing

This is where the ruthless advice usually goes wrong, and it is why some MVPs fail for reasons that have nothing to do with demand.

A way to take money, if the proof is that people will pay. An email list is not proof. A card charge is.

Reliability inside the narrow scope. Users forgave rough software in 2012. They do not now. One excellent, working path beats five half finished ones, and a broken MVP produces a rejection of your execution that founders then misread as a rejection of the idea.

The legal minimum. Terms, privacy, consent, and whatever your sector demands. Not optional and not expensive.

A way to contact you and be answered. Your first users are co authors. If they cannot reach you easily, you lose the most valuable thing the launch produces.

Enough measurement to see what happened. Not analytics for its own sake. Two or three numbers tied to the proof.

A worked way to cut

Write every feature you can think of on one list. Then draw three columns.

Proof. Required for a user to complete the outcome and for you to see whether they value it.

By hand. Real work you will do manually at launch: matching, scheduling, checking, sending, verifying. Fine, and often better than code.

Later. Everything else, in priority order, with a note saying why it waited.

Then remove one more thing from the proof column than feels comfortable. Every experienced team has learned this, because scope grows back on its own during a build, and the only defense is starting narrower than feels right.

Building is cheap now, which makes this harder

There is a new trap in 2026. Software is faster to build than it has ever been, so the cost of adding one more feature feels close to zero.

It is not zero. Every feature you ship is a thing to maintain, explain, support, and eventually migrate. More importantly, every feature added before the proof muddies the result. If you launch with eleven features and nobody comes back, you have learned nothing about which part failed.

The skill worth developing is no longer building quickly. It is deciding what not to build, and that has become more valuable precisely because building got easy.

How do you know if you have cut too far?

One test: can a real user complete something they genuinely wanted, end to end, and get the outcome without you explaining it to them? If yes, you are minimum but viable. If no, you have shipped a fragment, and the feedback you get will be about your product being unusable rather than about whether the idea is any good.

Those two failures look identical in a spreadsheet and are completely different in meaning. Keep them separate.

What to measure once it is live

Three numbers, tied to the proof, with a date attached.

Did the people you built it for actually complete the outcome. Did they come back or pay, which is behavior rather than opinion. And what did they ask for that does not exist yet, which is your roadmap arriving for free.

If those numbers are good, the next build is obvious. If they are bad, you have saved yourself a year, which is exactly what the MVP was for.

The quieter point

A first version is a question, not a product. The narrower the question, the clearer the answer, and the cheaper it is to ask again if the answer is not the one you wanted.

That is how we scope first builds: one outcome, done properly, with the parts that can be handled manually left manual until real use proves they need automating.