What Is an MVP App? Meaning, Types and How to Scope Yours

In app development, an MVP (minimum viable product) is the smallest version of your app that solves one core problem for one type of user, well enough that real people use it and you learn whether to keep going. It's a working product, not a mockup. But it does only the one thing that matters most, and leaves everything else for later.

This guide explains what MVP means in app development, what it isn't, the main types, and a practical framework for scoping yours, with a worked example, typical costs and the metrics that tell you whether it worked.

What is MVP in app development?

The term comes from Eric Ries and the Lean Startup movement. His definition: "The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort" (Lean Startup Co., originally published 2009).

The key word is learning. An MVP exists to answer a question, usually "will the people I think have this problem actually use this to solve it, and keep using it?" Ries himself notes that "MVP, despite the name, is not about creating minimal products."

So the two halves of the name pull against each other on purpose:

• Minimum: cut everything that doesn't help answer your main question.
• Viable: what's left has to genuinely work and deliver value. If it's too broken or confusing to use, you learn nothing.

What an MVP is not

It's not a cheap, buggy app

A buggy MVP gives you bad data. If users leave, you won't know whether they didn't want the product or just couldn't get it to work. Build less, but build the core flow properly.

It's not a prototype

A prototype, even a clickable one, tests whether people understand your idea and can move through it. An MVP tests whether they use it in real life, with real data, over time. You usually make a prototype first, then the MVP.

It's not version 1 of everything

"MVP" often gets stretched to mean "the full product, but launched sooner." If your MVP has three user roles, a chat feature and an admin dashboard, it's probably not minimum.

	Prototype	MVP	Full v1
Purpose	Test understanding and usability	Test real use and value	Serve a growing market
Real users and data?	No, simulated	Yes	Yes
Scope	Core flow, clickable	One core flow, working	Many flows and features
Typical tool	Figma	Code or no-code	Code

The five main types of MVP

You don't always need to build software to run an MVP. Pick the cheapest type that answers your question.

1. Concierge MVP

You deliver the service by hand, openly. If your app will match tutors with students, you do the matching yourself over email. It tests whether people value the outcome, before you automate anything.

2. Wizard-of-Oz MVP

The user sees what looks like a real product, but a person does the work behind the scenes. Zappos started this way: founder Nick Swinmurn photographed shoes in local stores, listed them online, and when someone ordered, bought the pair at the store and shipped it (Selling Power). It proved people would buy shoes online before any inventory or logistics existed.

3. Single-feature MVP

A real app that does one thing. No settings screen worth mentioning, no social features, just the core job. This is what most people mean by an "MVP app," and it's usually the right choice once you've validated demand.

4. No-code MVP

The same idea, built with no-code or AI app-building tools instead of custom code. It's faster and cheaper to start, with limits on custom logic, performance and scale. Many teams rebuild in code once they've proven demand.

5. Clickable prototype (or demo) MVP

Strictly speaking, this sits just before an MVP, but it's often used as one. Dropbox famously used a demo video of the product to build its beta waitlist before the product was ready for the public (Alexander Jarvis). A clickable prototype tested with target users can validate the flow and the pitch at a fraction of the cost of building.

How to scope your MVP: a 5-step framework

Step 1: Write the core job in one sentence

Use this format: "When [situation], I want to [action], so I can [outcome]."

For example: "When a client cancels at short notice, I want to fill the slot quickly, so I don't lose the income."

Every feature you consider has to serve this sentence. If it doesn't, it's not in the MVP.

Step 2: Pick one user and one platform

If your product has two sides (buyers and sellers, trainers and clients), decide which side you must win first. Then pick one platform: iOS, Android or web. Supporting everything doubles work and halves focus.

Step 3: Map one core user flow

Write the steps from "opens the app for the first time" to "gets the outcome." Aim for the fewest steps that still work. This flow is your MVP. Everything else is support.

Step 4: Sort features with MoSCoW

List every feature you can think of, then sort them into four groups. The method comes from the DSDM agile framework (Agile Business Consortium):

• Must have: the product doesn't work without it.
• Should have: important, but the product is still viable without it.
• Could have: nice if time allows.
• Won't have (this time): explicitly out, for now.

The Agile Business Consortium recommends that Must Haves take no more than about 60% of the effort, with roughly 20% for Could Haves as contingency. For an MVP, be even stricter: if you're unsure whether something is a Must, it isn't.

Step 5: Decide how you'll judge it, before you build

Pick two or three metrics and write down what result would make you continue, change direction or stop. Deciding afterwards makes it too easy to explain away bad numbers. (More on metrics below.)

Example: scoping an MVP for a sample app

Here's the framework applied to a made-up app for independent personal trainers who lose money to last-minute cancellations.

Core job: When a client cancels late, I want to fill the slot quickly, so I don't lose the income.

One user, one platform: Trainers first (clients get a simple web link, no app). iOS only, assuming interviews showed most of these trainers use iPhones.

Core flow:

1. Trainer signs up and adds their regular clients.
2. A client cancels; the trainer taps "Fill this slot."
3. The app texts the waitlisted clients a booking link.
4. The first client to tap the link books the slot; the trainer is notified.

Priority	Features
Must	Sign-up, client list, "fill this slot," SMS booking link, booking confirmation
Should	Basic calendar view, reminder notifications
Could	Simple stats on slots filled, custom message templates
Won't (this time)	In-app payments, client app, group classes, Android, chat

Notice what's missing: payments. They matter, but the MVP question is "will trainers use this to fill slots?" Payments can wait until the answer is yes.

How long does an MVP take, and what does it cost?

Published figures vary a lot, mostly because sources define "MVP" and "included" differently:

• Techtic (August 2026) puts a simple MVP at $5,000–$25,000 over 4–8 weeks, a standard MVP at $25,000–$80,000 over 8–16 weeks, and a complex one at $80,000–$150,000 over 16–24 weeks.
• Droids On Roids (2026), a European agency, says most MVPs that include discovery, design and backend start at around $150,000.
• Clutch reports most app development projects on its platform cost $10,000–$49,999, with an average of $90,780 (September 2026).

The gap between $5,000 and $150,000 is real. It reflects region, team type, whether design and backend are included, and how "minimum" the scope actually is. The surest way to lower the number is a tighter scope, not a cheaper team.

Design is usually a smaller, separate piece. Jotform (2026) puts design for a simple MVP of 5–15 screens at $3,000–$15,000 over 2–4 weeks. Our breakdown of how much it costs to design an app covers this in detail, and Iroko Digital's app design service starts at $2,500 at a fixed price, with designs ready in 3–6 weeks.

Metrics to judge an MVP

Pick a few, set targets in advance, and watch them for several weeks:

• Activation: what share of sign-ups reach the core outcome (in the example, fill one slot)?
• Retention: do people come back in week two and week four without being chased? This is the most honest signal you'll get.
• Frequency: how often do active users do the core action?
• Willingness to pay: will anyone pay, pre-pay or commit to a paid plan?
• The "very disappointed" test: Sean Ellis's product-market fit survey asks users how they'd feel if they could no longer use the product. If more than 40% say "very disappointed," that's a strong sign of fit, a benchmark he drew from comparing nearly 100 startups (Learning Loop). Treat it as a guide, not a law, and wait until you have enough real users to ask.

Pair the numbers with conversations. Retention tells you that people leave; a five-minute call tells you why.

Common MVP mistakes

• Building before validating. If you haven't talked to potential users yet, start with our roadmap on what to do when you have an app idea.
• Too many Must Haves. If everything is essential, nothing is prioritized.
• Building for two sides at once when one side could be handled manually.
• Skipping design and going straight to code, then rebuilding flows that a prototype would have caught.
• Polishing the wrong things. Animations and custom illustrations before the core flow works.
• No success criteria, so every result looks like a reason to keep going.
• Treating launch as the finish line. The MVP is the start of learning, not the end of the project.

FAQ

What is an MVP in app design?

In app design, an MVP means designing only the screens and states needed for the one core user flow, plus essentials like sign-up. The designer's job is to make that flow clear and usable, and to leave room to add features later without a redesign. It's usually tested as a clickable prototype before development starts.

How many features should an MVP app have?

As few as it takes to deliver the core outcome. A better test than counting features: can a new user go from opening the app to getting value through one clear flow? If a feature isn't part of that flow, it can probably wait.

Is an MVP the same as a prototype?

No. A prototype simulates the product to test whether people understand it and can use it. An MVP is a working product that real users rely on, which tests whether they actually want it.

How long does it take to build an MVP app?

Estimates range from about 4–8 weeks for a simple MVP to several months for complex ones, according to 2026 agency guides like Techtic's. Design typically adds a few weeks before development, and a tight scope is the biggest factor in how fast you ship.

What comes after an MVP?

You review your metrics and user feedback, then decide to continue, change direction or stop. If you continue, you add the Should Haves that users actually asked for, improve retention, and only then expand to new platforms or user types.