How to Build an MVP: Scope, Speed and What to Leave Out
A practical guide to building a minimum viable product — defining the riskiest assumption, MVP types, scoping ruthlessly, choosing no-code vs code, measuring learning and what comes after.
A minimum viable product (MVP) is the smallest thing you can build to learn whether your idea is worth pursuing. The term is widely misused, either as an excuse for shipping something broken or as a label for a "version one" that took nine months. Done right, an MVP is a focused experiment that answers your riskiest question as quickly and cheaply as possible.
Key takeaways
- An MVP exists to test your riskiest assumption, not to launch a small version of the full product.
- Many MVPs involve little or no code: landing pages, concierge services, prototypes.
- Scope ruthlessly around one core job for one target user.
- "Minimum" doesn't mean low quality. The part you build must be viable: it must actually solve the problem.
- Define success criteria before launching, so the result is a clear signal, not a vague feeling.
Start with assumptions, not features
Every product idea rests on assumptions:
- Problem: this user has this problem, and it's painful enough to act on.
- Solution: our approach solves it better than alternatives.
- Willingness to pay: they'll pay (or engage) at a viable price.
- Channel: we can reach them affordably.
- Feasibility: we can build and deliver it.
List them, then ask: which one, if wrong, kills the idea, and is the least proven? That's what your MVP should test. Often it's problem severity or willingness to pay, not technical feasibility.
Types of MVPs
| MVP type | How it works | Tests |
|---|---|---|
| Customer interviews | Structured conversations about problems and current behavior | Problem existence and severity (product discovery) |
| Landing page / fake door | Describe the product, measure signups or pre-orders | Demand, messaging, channel |
| Clickable prototype | Figma-style prototype tested with users | Usability, solution fit |
| Concierge MVP | Deliver the service manually for a few customers | Value of the outcome, workflow |
| Wizard of Oz | Looks automated to users; humans do the work behind the scenes | Demand for an automated solution before building it |
| Single-feature product | Build just the core feature, well | Retention on the core job |
| No-code product | Built with no-code tools | Real usage without heavy engineering |
| Pre-sales / letters of intent | Sell before building (common in B2B) | Willingness to pay |
Wizard of Oz is especially powerful for AI products: test whether users value AI-generated output by having humans (or humans plus AI) produce it first, before investing in automation (AI product management).
Scoping: the art of leaving things out
Define:
- Target user: narrow and specific. "Operations managers at 20–100 person logistics companies" beats "businesses".
- Core job: the one outcome your MVP delivers. Everything else is secondary.
- Must-haves only: what's strictly required for a user to get that outcome.
Things usually safe to cut or fake in an MVP:
- Admin panels (use the database or a spreadsheet).
- Complex settings and permissions (start with sensible defaults).
- Multiple integrations (support one, or a CSV import).
- Automated billing (send invoices manually at first).
- Scalability work beyond realistic early usage (how to scale a web application covers when it's actually needed).
- Edge-case polish for users you don't have yet.
Things not to cut:
- The core experience being genuinely useful.
- Basic security and data protection (these aren't optional).
- The instrumentation you need to learn: analytics on the key actions.
- A way for users to give feedback and reach you.
Use MoSCoW to make scope decisions explicit (prioritization frameworks).
Build approach: no-code, low-code or code?
| Approach | When it fits |
|---|---|
| No-code (Webflow, Framer, Bubble, Airtable, automation tools) | Validating demand and workflows quickly, especially for non-technical founders |
| Low-code + small custom pieces | Standard CRUD workflows plus one differentiating capability |
| Custom code | The core value is technical (AI, data processing, performance) or needs deep integrations |
Many successful products started on no-code or with heavy manual work behind the scenes, then rebuilt the core in code once demand was proven (choosing a tech stack, n8n vs Zapier vs Make).
If you write code, keep it simple: a monolith, a managed database, a PaaS host. Pick boring technology and move fast (monolith vs microservices).
Define success criteria up front
Before launch, write down what result would make you continue, pivot or stop:
- "At least 30% of trial teams complete the core workflow twice in their first week."
- "At least 10 of 40 interviewed prospects agree to a paid pilot at the target price."
- "Landing page converts at 5%+ from targeted traffic to waitlist signup."
Choose metrics that measure real behavior (usage, retention, payment), not opinions. People are generous with compliments and stingy with money and time. The signal is in the latter (product metrics that matter).
Launch small and learn fast
- Start with a handful of well-matched users you can talk to directly.
- Onboard them personally at first; you'll learn more from watching one user struggle than from any dashboard.
- Instrument key actions and talk to users weekly.
- Iterate in short cycles: days to a couple of weeks, not months.
Interpreting results
- Strong pull (users come back unprompted, ask for more, pay): double down, and start building for reliability and scale.
- Mixed signals: dig into segments. Maybe a sub-group loves it, and that's your real market.
- Weak engagement: is it the problem (not painful enough), the solution, the user segment or the channel? Revisit your assumptions and pivot one of them deliberately.
Progress toward product-market fit is a sequence of these learning cycles (product-market fit).
Common MVP mistakes
- Building too much: a six-month "MVP" isn't minimal.
- Building too little of the core: a buggy core experience tests nothing except tolerance for bugs.
- Testing the easy assumption: proving you can build it instead of proving anyone wants it.
- No success criteria: every result gets rationalized as "promising".
- Wrong users: feedback from friends or the wrong segment leads you astray.
- Ignoring qualitative feedback: numbers tell you what, conversations tell you why.
After the MVP
Once you've validated the core, shift gradually toward:
- Reliability and quality of the core experience.
- Onboarding and activation improvements.
- Scalable architecture where usage demands it, paying down deliberate shortcuts (technical debt management).
- Roadmapping based on evidence (roadmap planning).
FAQ
How long should it take to build an MVP?
It depends on what you're testing, but aim for weeks, not months. Many valuable MVPs (landing pages, prototypes, concierge tests) take days. If your MVP plan exceeds about three months, look for a smaller experiment that tests the riskiest assumption sooner.
How much does an MVP cost?
It ranges from almost nothing (interviews, landing pages) to a meaningful engineering investment for technical products. Spend in proportion to the confidence you've already gained. Validate cheaply before building expensively.
Should an MVP be free?
Charging, even a small amount, is one of the strongest validation signals, especially in B2B. Free pilots can work when the goal is to learn about usage, but make sure you test willingness to pay before scaling.
What's the difference between an MVP and a prototype?
A prototype demonstrates or tests how something might work, often without real functionality. An MVP delivers real value to real users, however minimal, so you can observe actual behavior.