MVP app: what belongs in the first version and what doesn't

Short answer: An MVP (minimum viable product) is the smallest version of an app that already solves one real problem for real users and lets you measure whether they want it. An MVP includes one main user journey from start to finish, basic security and measurement. It does not include everything that would be “nice to have”, nor preparation for scale that hasn't arrived yet.

Why it matters

MVP is a term everyone knows and everyone uses differently. For some it is a clickable prototype, for others a product with every feature, just a bit cut down. Yet how you interpret it decides how much money and how many months you spend before you learn anything.

For a person who decides on the budget, the difference is fundamental. An MVP that is too small proves nothing, because people can't use it. An MVP that is too big burns money and months before you find out whether anyone wants the product at all. And with the rise of vibe coding, a third trap has appeared: the MVP gets built over a weekend, but nobody asked what it should prove.

Planning your first version and not sure where to draw the line? Book 30 minutes online with us. We will go through your feature list and tell you what we would leave for later. Book an online call

What an MVP is and what it isn't

An MVP is an experiment, not a small product. Eric Ries popularised the term in The Lean Startup (2011) as the version of a product that lets you learn as much as possible about customers with the least effort. The key word is “learn”. An MVP should answer a question, not show off everything you can build.

That tells you what an MVP is not:

• It is not a prototype. A prototype shows what the product could look like. An MVP is already used by real people, and you measure what they do.
• It is not a beta of the full product. A beta is a finished product with bugs. An MVP is a deliberately incomplete product without bugs in the little it does.
• It is not a cut-down version. You don't save on the quality of the main feature. You save on the number of features.

At MeguMethod we ask one question before anyone starts talking about features: what question should the first version answer? If we can't put it in one sentence, it is not yet time to build.

What belongs in an MVP

An MVP contains one user journey that a person can complete without help. Everything else is a candidate for removal.

• One main journey from start to finish. The user arrives, does what they came for and leaves with a result. In a booking app it is the booking, in a reporting tool one finished report. Not five journeys done halfway.
• Login and basic security. As soon as the app stores data about people, everyone must see only their own. That is not an extra feature, it is the condition for giving the app to strangers.
• Measurement. How many people came, how many completed the main journey, how many returned. Without these three numbers, an MVP proves nothing, even if it works.
• A way for users to tell you what's missing. A form, an email, a button. The most valuable output of an MVP is sentences from people, not charts.
• Backups and a separate environment. The smallest possible version of operational hygiene. Losing the data of your first ten customers is worse than a missing feature.

What doesn't belong in an MVP

An MVP should contain nothing that solves a problem you don't have yet. That is the simplest test for every feature request.

• Role and permission management for large teams. While you have ten customers, a user and an admin are enough.
• Integrations with everything. One integration that the main journey needs, yes. Connections to five systems “because customers will want it”, no. When they want it, they will tell you which one.
• Preparing for scale. An app for a hundred users doesn't need to be built for a hundred thousand. It needs to be built so it can be rebuilt when those hundred thousand arrive.
• A custom design system and animations. An MVP should be clear and trustworthy. It doesn't have to be beautiful.
• A native mobile app when the web will do. If the main journey doesn't need the camera, location or notifications, the web on a phone will prove the same thing in a fraction of the time.
• Settings, options and customisation. Every choice you give the user is a decision you didn't make. In an MVP, you decide.

A practical approach: write down every feature you can think of and for each one ask, “will this feature prove what we want to know?”. Whatever gets a no goes on the later list. Don't throw that list away, it is the basis of your second version.

How big should an MVP be

You can tell an MVP is the right size when you are a little embarrassed by it, but users can use it without you. If you have to explain to everyone where to click, it is too small. If you have been building it for six months, it is too big.

A good rule of thumb is the time to your first real user. If you count it in weeks, you are on the right track. If you count it in months, there is something in the scope that doesn't belong there. That holds whether you build the MVP with AI tools, in-house or with a partner.

MVP with AI, or with a team?

Vibe coding has changed the economics of an MVP. A first version that used to take weeks of a developer's work can now be put together by a founder in a few days in a tool like Lovable or with Claude Code. That is good news, as long as you know what you are trying to prove.

Our view at MeguMethod: AI tools are the best route to an MVP that should prove demand. Once it turns out the demand is there, the second phase begins: turning the MVP into a product that holds up in production. That is more often a job for a team, because it involves security, integrations and performance, things a prompt handles worse than a person. What exactly needs finishing in that phase is described in our checklist for getting an AI-built app ready for real users.

The important thing is not to decide once and for all. An MVP with AI and a product with a team are not two competing routes, but two phases of the same route.

When to build an MVP and when not yet

Build an MVP when:

• you can say in one sentence what it should prove,
• you have at least ten people who will use it and tell you what they think,
• you know which number will mean success and which won't,
• your budget is measured in weeks, not months.

Wait a little longer when:

• you are choosing between three different ideas and the MVP is supposed to cover all of them,
• you have nobody to ask whether they want the product and plan to find out only through ads,
• the main user journey depends on an integration you haven't agreed on yet,
• the first version has to meet legal or contractual requirements that an MVP can hardly meet (healthcare, finance). There you start differently.

If the second list sounds like you, it is not yet time for an MVP but for discovery: a short phase in which you clarify the problem, the users and possible solutions before anything gets built. At MeguMethod we run it as a strategy analysis with a small team made up of a product lead, a UX/UI designer and a senior developer. The output is a map of users and their journeys, alternative solutions and a proposed architecture, which let you define the first version with confidence.

Have an idea and want to validate it before putting serious money in? See how our strategy analysis works, or send us a few sentences about what the first version should answer. We will prepare a discovery workshop tailored to you. Send an inquiry

How MeguMethod approaches it

When it is not yet clear what the first version should prove, we start with a strategy analysis, a discovery phase in which we map the users, their journeys and alternative solutions with you. Bad ideas get dropped before they can cost money.

When the goal is clear, the first step in App as a Service is a meeting where we agree on the goal, scope, timeline and price. There we ask one question before we talk about features: what should the first version answer? Then we turn the idea into an app and launch it live, without mockups or clickable prototypes, because the first version should be something people actually use. It comes with architecture, tests and deployment rules, so it can be built on.

What doesn't make it into the first version isn't lost. We add it to the development plan and go through it with you at regular reviews. You can then make further changes with AI yourself, with our tools and guidance, and every change is checked by our AI and our experts before it goes live. How App as a Service works

Next step

Have a first version and want to turn it into a product for customers? See how App as a Service works, or book 30 minutes online. And if you don't yet know what the first version should prove, start with a strategy analysis.