Minimum Viable Product (MVP)

What Is an MVP?

A Minimum Viable Product (MVP) is the smallest, simplest version of a product that still delivers enough value to real users to test whether your core assumptions are correct. It is not a smaller version of your final product. It is a learning tool built to answer one question: will people actually use and pay for this?

The term comes from Eric Ries's Lean Startup methodology, where "viable" does the heavy lifting. Viable means the product actually solves a real problem for a real user, even if it is ugly, manual, or missing 90% of the features on your roadmap.

Why MVPs Matter for Early-Stage Founders

Most startups do not fail because they built the wrong features. They fail because they spent months or years building a full product before finding out nobody wanted it. An MVP flips that risk:

• It saves runway. You test demand before spending your fundraising or bootstrapped capital on a full build.
• It surfaces the real problem. Users often want something different from what you assumed. An MVP exposes that fast and cheap.
• It creates a feedback loop. Build, measure, learn. Each MVP cycle should sharpen your understanding of the customer.
• It de-risks fundraising. Investors want evidence of demand, not just a pitch deck. Even a scrappy MVP with real usage data is more convincing than a polished mockup.

For a founder deciding what to launch first, the goal is not "what can we build in two weeks" but "what is the smallest thing that tests our riskiest assumption."

How to Build an MVP

Step 1: Identify your riskiest assumption

Every product idea rests on a chain of assumptions: that the problem exists, that people will change behavior to solve it, that they will pay, that you can acquire them affordably. Find the assumption that, if false, kills the whole business. That is what your MVP should test first.

Step 2: Strip the solution to its core

Ask what is the least amount of product you can build (or fake) that still lets a real user experience the core value. Common MVP formats, roughly ordered from cheapest to most built-out:

1. Landing page MVP: A page describing the product with a signup or waitlist button, used to test demand before writing code.
2. Concierge MVP: You manually deliver the service behind the scenes (Zapier, spreadsheets, DMs) while the user thinks it is automated.
3. Wizard of Oz MVP: The interface looks automated, but a human is doing the work behind the curtain.
4. Single-feature MVP: A working product with exactly one core feature, no settings, no edge cases.
5. Piecemeal MVP: Stitching together existing tools (Airtable, Typeform, Stripe) to simulate the full experience.

Famous examples: Zappos founder Nick Swinmuern manually photographed shoes from local stores and posted them online to test if people would buy shoes without trying them on first, before any inventory or warehouse existed. Dropbox validated demand with a simple explainer video before building the syncing technology, generating tens of thousands of signups overnight.

Step 3: Define success metrics before you launch

Decide in advance what result would validate or invalidate your assumption. Vague goals like "see how it goes" produce vague, self-serving conclusions. Example criteria:

• 30% of landing page visitors join the waitlist
• 10 of 20 concierge customers pay for a second month
• Users complete the core action within their first session at least 40% of the time

Step 4: Ship fast, then measure and decide

Get the MVP in front of real users within days or a few weeks, not months. Track the metric you defined. Then make an explicit decision: persevere (double down on this direction), pivot (change the approach but keep learning), or kill it.

A Simple MVP Scoping Framework

When deciding what to cut, run every proposed feature through this filter:

Include it only if removing it would prevent you from testing the core assumption.

Everything else, including account settings, admin dashboards, onboarding polish, and edge-case handling, waits until after you have validated demand.

Common Mistakes

• Confusing "minimum" with "low quality." The MVP still has to be viable, meaning it genuinely solves the problem for the user, even if it looks rough.
• Building for too long. If your MVP takes more than 4 to 8 weeks to ship, it is probably not minimum. Cut scope further.
• Skipping the metric. Without a predefined success threshold, teams rationalize weak results as "promising signs."
• Testing the wrong assumption. Teams often validate that people like the idea in conversation, which is not the same as validating that they will use or pay for the product.
• Never graduating from MVP mode. Some teams treat every release as an MVP indefinitely and never invest in the reliability and polish a growing user base needs.

A well-scoped MVP is the fastest, cheapest path to real evidence. Teams using platforms like welaunch.sh to get a landing page or waitlist live in a day often use that exact motion as their first MVP test, validating interest before writing a line of core product code.