What to include in your MVP's first version (and what to cut)

The hardest part of building an MVP is rarely the engineering. It is deciding what goes in the first version and, more importantly, what gets left out. Get this wrong and you either ship something too thin to learn anything from, or you spend months building features nobody has asked to use yet.

Start from the core loop, not the feature list

Every product has one core loop — the sequence of actions a user repeats that actually delivers value. For a marketplace, it is list, discover, transact. For a SaaS tool, it is input data, get useful output, come back. Your first version should make that loop work end to end, properly, before anything else gets built.

What almost always belongs in version one

• Account creation and login. Even a minimal version — people need an identity in the system to generate real, attributable data.
• The one thing that makes the product valuable. Not three things, done shallowly. One, done properly.
• A way to see the result. Dashboards, notifications, confirmations — whatever closes the loop and tells the user something happened.
• Basic error handling. Not polish, but the product should not silently fail when real users do unexpected things, which they always do.

What almost always should wait

• Settings and customisation. Power-user features for a product with no users yet is effort spent on a problem you do not have.
• Admin tooling beyond the basics. Do what you can manually before building an interface for it.
• Scale-driven architecture. Caching layers, microservices, elaborate infrastructure — these are solutions to a traffic problem you are unlikely to have on day one.
• Secondary user types. If your product eventually serves three kinds of users, build for the one that proves the model first.
• Anything "nice to have." If a feature's absence would not stop someone completing the core loop, it is not version one.

A simple test for any feature

Ask: if we removed this, could someone still complete the core loop and get real value? If yes, it is a candidate to cut. If removing it breaks the loop entirely, it probably belongs in the first version.

This is exactly the discipline behind our BUILD.ONE sprint — one week, one core feature, built properly and put in front of real users, with everything else deliberately left out until the core is proven. If you want help applying this to your own idea, our MVP cost calculator is a good place to start scoping what version one actually needs.