What Is an MVP? A Plain-English Definition

An MVP is the smallest version of your product that lets a real person do the one thing that matters, so you can learn whether they actually want it. MVP stands for “minimum viable product.” The goal is not to ship something small for the sake of it. The goal is to test your riskiest assumption with the least amount of work, before you spend months building the wrong thing.

Most people get this wrong in the same way. They hear “minimum” and picture a broken, ugly, half-finished app. So they either build a bloated product to avoid looking amateur, or they ship something so bare it does nothing useful. Both miss the point. An MVP is not a worse version of your product. It is the fastest honest test of whether the product should exist at all.

What does MVP actually mean?

The word that trips everyone up is “viable.” Viable means it works well enough for one real person to complete one real task and get one real result. If it can’t do that, it’s not viable, it’s just unfinished.

Break the term down:

• Minimum — you cut everything that isn’t required to test your main assumption. Fewer features, not lower quality.
• Viable — it genuinely solves one problem for one user, start to finish.
• Product — a real person can use it without you sitting next to them explaining what to click.

Here’s the mental test. Pick the single most important thing a user comes to your product to do. Call it the core action. Your MVP is whatever it takes to let them do that core action and nothing else. Everything past that is a feature you’re guessing about.

Does an MVP have to be an app?

No. This is the biggest myth, and it wastes the most time. An MVP does not have to be code at all. It can be a spreadsheet, a signup page, a form, or you doing the work by hand behind the scenes.

The point of an MVP is learning, not building. If you can learn the same thing with a Google Form that you’d learn with a polished app, the Google Form wins because it took an afternoon instead of two months. Founders who insist on building the “real” thing first usually spend that time avoiding the scarier question: does anyone want this?

The main types of MVPs

There’s no single shape an MVP has to take. The right one depends on what you’re trying to learn and how much you can fake versus build. Here are the four most common types.

Type	What it is	Best for	What you fake
Landing page	A single page describing the product with a signup or “buy” button that captures interest	Testing whether people want the thing at all	The entire product; you measure clicks and signups instead
Concierge	You deliver the service manually, by hand, for your first users	Services and workflows where the value is the outcome, not the software	Nothing is automated; you are the product
Wizard of Oz	The user sees a working product, but a human does the work behind the curtain	Testing a magical-feeling automated experience before you build the automation	The “engine”; a person does what looks automated
Single-feature	A real, working product stripped to one core action only	When you know people want it and need to prove the core loop works	All secondary features; you ship the one that matters

A concierge MVP means you personally do the work your product will eventually automate. If you’re building a tutoring-match service, you match the first ten students by hand over text. You learn what people actually want before you write a line of code.

A Wizard of Oz MVP looks automated to the user but isn’t. They submit a request, it feels instant and magical, and behind the scenes you’re doing it manually. They never know the difference, and you learn whether the experience is worth automating.

If you want to go deeper on the build-focused paths, read our guide on how to build an MVP with no code, which walks through the tools that let you ship a working product without programming.

How small is small enough?

Small enough that it does exactly one core action and nothing else. If you can remove a feature and still test your main question, remove it.

Use this rule: write down the one sentence a happy user would say after using your product. Something like “I found a tutor in five minutes” or “I sold my old textbooks without leaving my dorm.” Your MVP is whatever makes that one sentence true. Every feature that doesn’t serve that sentence is a distraction you’re adding to feel safe.

A simple way to find the core action:

1. Name the single problem you’re solving. One problem, not three.
2. Describe the one moment where the user gets value. The exact click, message, or result.
3. List every feature you imagined. Be honest and write them all down.
4. Cross out anything the user could live without on day one.
5. What’s left is your MVP. It should feel almost uncomfortably small.

If it doesn’t feel too small, you probably haven’t cut enough. The most common mistake in building an MVP is quietly adding “just one more thing” until the minimum isn’t minimum anymore.

What an MVP is not

An MVP gets blamed for a lot of things it isn’t. Clearing these up saves you weeks.

• It’s not a broken or buggy product. The one action it does should work reliably. Minimal scope, not minimal quality.
• It’s not a prototype you never show anyone. An MVP goes in front of real users. If nobody outside your friend group touches it, you learned nothing.
• It’s not version 1.0 of your master plan. It’s a test. You might throw it away, and that’s a success if it taught you something.
• It’s not “everything, but cheaper.” Cutting corners on every feature gives you a bad product. Cutting the number of features gives you an MVP.
• It’s not the finish line. Shipping an MVP is the start of learning, not the end of building.

The thread through all of these: an MVP exists to answer a question. If you can’t say out loud what question your MVP is answering, you’re building, not testing.

Why teen founders should love the MVP mindset

You have less time and less money than a funded company, and that’s an advantage here. It forces you to cut. A high schooler who ships a scrappy landing page and talks to twenty real users will out-learn someone who spent a summer coding a product nobody asked for.

This is the whole idea behind the first week of the batch0 program: validate before you build. You test the idea with the smallest thing possible, then earn the right to build the next piece. It keeps you from falling in love with a product before you know anyone wants it.

Before you build anything, it helps to be sure you’re solving a real problem. Our guides on how to validate a startup idea in high school and how to test a business idea before you build it walk through exactly how to do that without writing code.

How to build your first MVP, step by step

Once you know your core action, the build is faster than you think. Here’s the honest sequence.

1. Write the one sentence a happy user would say. This is your target.
2. Pick your MVP type from the table above. Landing page if you’re testing demand, concierge or Wizard of Oz if you’re testing the experience, single-feature if you’re testing the core loop.
3. Build the smallest version that makes the sentence true. Use no-code tools or your own hands. Don’t over-engineer.
4. Put it in front of real users — not friends who will be nice, but people who have the problem.
5. Watch what they do, not what they say. Where do they get stuck? Do they come back? Do they pay?
6. Decide: keep going, change direction, or drop it. Then repeat with the next riskiest question.

If demand is what you’re testing, a well-built page does a lot of the work. Learn how to build a landing page that converts so your test measures real interest and not just polite curiosity.

How long should building an MVP take?

Days to a few weeks, not months. If your MVP is taking two months, it’s not an MVP anymore, it’s a product built on a guess. The whole reason to keep it small is speed: the faster you get it in front of people, the sooner you know if you’re onto something. For a realistic breakdown by build type, see how long it should take to build your first MVP.

A rough guide: a landing page or a concierge test should take days. A single-feature no-code build should take a week or two at most. The moment you catch yourself adding features “so it’s ready,” stop and ship what you have.

Once your MVP proves people want the thing, the next real question is money. When you’re ready for that, our guide on how to price your first product covers how to charge without scaring people off or leaving value on the table. Ship small, learn fast, and let real users tell you what to build next.