What belongs in your MVP (and what to cut)

Most MVPs are not minimal. Founders pack in features out of fear of looking unfinished, and end up with something expensive, slow to build, and unfocused. The skill is subtraction. Here is how.

The short answer

Your MVP should include only what is needed to deliver the core value and learn whether the product works. For every feature, ask: "Can we do those two things without this?" If yes, cut it. The MVP is the smallest thing that solves the main problem, not a small version of the whole vision.

The one question

For each proposed feature, ask: "Can we deliver the core value and learn what we need to learn without this?"

• If yes, cut it. It can come later.
• If no, it stays.

Run every feature through this and most will fail it. That is correct. An MVP is defined by what it leaves out.

What usually belongs

• The single core action that delivers the main value.
• The minimum around it to make that action usable (basic accounts if truly required, the one key screen).
• Whatever you need to measure success.

What usually gets cut

• Settings, customization, and edge cases.
• Secondary features that are "nice."
• Polish, animations, and breadth of options.
• Anything serving a user segment that is not your first target.

Why founders over-build (and why it backfires)

It feels safer to include more. But every extra feature is more cost, more time, more that can break, and more distraction from the core. Worse, it delays the learning that actually de-risks the product. A bloated MVP is slower to ship and teaches you less.

Scope it, then build it

Deciding what belongs is scoping; doing it well is the difference between a fast, cheap first version and a slow, expensive one (see how to scope an MVP). Once the core is defined, a product simulation turns exactly that scoped core into a documented, runnable foundation, so you build the right small thing well, instead of a big thing badly.

Know your core? Start a project for a clear, flat-rate scope.