What Is an MVP? A Practical Guide for Startup Founders

Ask five founders to define “MVP” and you’ll often get five slightly different answers — a smaller app, a rough prototype, “the bare minimum,” or a specific list of must-have features. Most of these aren’t wrong exactly, but they miss the actual point of the concept, which is less about size and more about what question you’re trying to answer.

This guide skips the theory and focuses on what actually matters for a founder deciding what to build first: what an MVP really is, the different forms it can take, and a practical way to choose between them.

What an MVP Actually Is

An MVP — Minimum Viable Product — is the smallest version of a product that can still deliver real value to a specific group of users, built specifically to test whether your core assumption about the market is correct. It isn’t a stripped-down version of your full vision; it’s a focused tool for learning, built around one central question you don’t yet have a confident answer to.

That question is usually some version of: will people actually use (or pay for) a solution to this problem? Everything about how an MVP is scoped should be in service of answering that question as cheaply and quickly as honestly possible — not in service of shipping as many features as the budget allows.

The Types of MVP You Can Actually Build

Most founders default to assuming “MVP” means a smaller working app. In practice, several formats exist, and picking the right one for your specific uncertainty saves significant time and money.

Landing Page MVP

A single page describing the product, with a clear call to action — sign up, join a waitlist, pre-order. It tests demand and messaging before any product work begins. Cheap, fast, and genuinely useful when your biggest uncertainty is “does anyone want this at all.”

Concierge MVP

You deliver the service manually, by hand, behind the scenes, before automating any of it. A founder personally matching customers with providers, or manually compiling a report a piece of software will eventually generate automatically. It’s slow to operate but extremely fast to learn from, because there’s no build time standing between the idea and real customer interaction.

Wizard of Oz MVP

The product looks automated to the user, but a human is doing the work manually behind the scenes. This tests whether the experience works before investing in the engineering to actually automate it.

Single-Feature MVP

A real, working product — but limited to one core feature that delivers the primary value, with everything else deliberately left out. This is the closest to what most people picture when they hear “MVP,” and it’s the right choice once you’re past testing pure demand and need to validate whether the actual product experience holds up.

Piecemeal MVP

Built by stitching together existing tools rather than custom software — a form tool, a spreadsheet, an off-the-shelf booking system — assembled to deliver the core experience without writing new code. Useful for testing an operational or service-based idea before committing to custom development.

How to Choose the Right Type for Your Idea

The right format depends on what you’re actually uncertain about:

Your biggest uncertainty	Best-fit MVP type
Whether anyone wants this at all	Landing page MVP
Whether the service model works, before automating it	Concierge MVP
Whether the automated experience will feel right to users	Wizard of Oz MVP
Whether the core technical solution actually works	Single-feature MVP
Whether an operational idea works before building custom software	Piecemeal MVP

It’s common to move through more than one of these in sequence — a landing page to test demand, then a concierge version to test the service model, then a real single-feature product once both are confirmed. Each stage exists to remove a specific uncertainty before spending more on the next one.

A Worked Example: Choosing a Format

Say you’re building an idea for a platform that matches freelance tutors with parents looking for after-school help. Your biggest open question isn’t whether the software can technically work — booking and messaging are well-understood problems. It’s whether parents will actually trust a new platform enough to book a stranger for their kids, and whether tutors will bother signing up before there’s a real base of parents to serve.

That points toward a concierge MVP first: manually match a handful of parents and tutors by hand, using nothing more than a form and some outreach, before writing a line of matching or payment code. If that manual process produces real, repeated bookings, you’ve validated the actual uncertainty — trust and two-sided demand — far more cheaply than building a full marketplace app would have, and you’ll build the eventual software with a much clearer picture of what the matching logic actually needs to handle.

Common Misconceptions Worth Correcting

“MVP means low quality.” An MVP should be narrow in scope, not poor in execution. A concierge MVP delivered badly teaches you less than one delivered well, because bad execution muddies whether users are rejecting the idea or just the experience.

“The MVP is a phase you finish and move past.” In practice, most successful products keep applying MVP thinking to every new feature — testing a focused version before building the full version — long after the original MVP has launched.

“You need to build software to have an MVP.” As the types above show, some of the most useful MVPs involve no custom software at all.

For a deeper look at why MVPs matter for startups more broadly — the benefits, real-world examples, and how MVPs differ from prototypes — see what an MVP is and why it matters for startups. And if the terminology itself, specifically what “MVP” means as used in software development teams, is what you’re trying to pin down, this breakdown of what MVP means in software development covers that more literally.

Turning This Into a Decision

Before choosing a format, write down, in one sentence, the single biggest thing you don’t yet know about your idea. That sentence should point you fairly directly to one of the five types above. If you can’t write that sentence yet, that’s usually a sign the next step isn’t building anything — it’s a round of customer conversations to figure out what you’re actually testing for.

Frequently Asked Questions

Is an MVP always a piece of software?

No. Some of the most effective MVPs aren't software at all — a landing page testing demand, a manual 'concierge' service delivered by hand, or a simple video explaining a concept. The point is testing an assumption cheaply, not building code for its own sake.

What's the most common mistake founders make when defining their MVP?

Treating the MVP as a smaller version of the entire product, feature by feature, rather than as a focused tool built to answer one specific question. That mindset tends to produce an MVP that's still too big, too slow to build, and too expensive to test cheaply.

How do I pick which type of MVP to build?

Match the type to what you're most uncertain about. If you're unsure people want the outcome at all, test with something manual or a landing page first. If the core uncertainty is technical feasibility, a working single-feature product is usually more useful than a non-functional mockup.

Does every startup need to go through an MVP stage?

Almost every startup benefits from some form of validated learning before a large investment, but the MVP doesn't have to look the same for every idea. The underlying principle — test cheaply before you build expensively — applies broadly, even when the specific format varies.