What is an MVP, and what should you build first?

An MVP ("Minimum Viable Product") is the smallest version of your product that lets you check your idea with real people. It is not a sloppy version: it is a version deliberately reduced to the essentials, so you can learn fast before investing more.

The analogy: the first step

You want to build a grand staircase to a floor you have never visited. Rather than building every step, you start with the first one and check that it leads in the right direction. If so, you continue. If not, you have lost far less than if you had built everything.

The MVP is that first step: solid, usable, but small.

What an MVP is not

• Not a throwaway prototype: it must really work, even on a reduced scope.
• Not a mediocre version: cutting features does not excuse neglecting the reliability of what you ship.
• Not the final version, smaller: it is a tool for learning, not a complete product in miniature.
• Not a synonym for "cheap": it costs less than a full product, but it needs care.

The principle: one question to validate

A good MVP answers one important question. For example:

• Do people really have this problem?
• Are they ready to use this solution instead of their current method?
• Does this specific journey work for them?

If your MVP tries to answer ten questions at once, it answers none of them well.

How to choose what to build first

1. Describe the problem in one sentence, from the point of view of the person who has it.
2. Identify the main user. Who are you building for first?
3. List everything you imagine, then cross things out without mercy. Keep what is essential for that person to solve their problem from start to finish.
4. Choose one complete journey rather than many half-finished features: the user must be able to go from the beginning to the end of a task.
5. Postpone the rest: options, settings, rare cases, sophisticated admin screens.

A practical test: "If I remove this feature, can my user still solve their problem?" If yes, it can wait.

An illustrative example

Imagine an app for a neighborhood shop that wants to handle click-and-collect orders. The MVP could be limited to: see the products, order, be notified when it is ready. No loyalty program, no statistics, no multi-shop. Those will come if usage confirms the interest.

What you should not cut

Even reduced, an MVP that welcomes real users has to keep a few promises: their data is protected, the application does not collapse at the first problem, and it can evolve afterwards. This is where AI tools that produce an application in a few hours show their limits: see Lovable, Bolt, Cursor: What Changes When AI Writes Code and vibe coding limits.

After the MVP

The MVP is not an end. Once launched, you observe: who uses it, what is used, what blocks people. Those observations decide what comes next. To frame things well before starting, see scoping a product.

Remember

An MVP is the smallest version that answers a real question with real people: small, but solid. Choose one user, one problem, one complete journey, and let the rest wait.

And for your product?

If you have an idea and want to define what to build first, our product build support turns the idea into a realistic first scope, then develops it. We can talk it over in a 30-minute call.