MVP vs. Prototype vs. Landing Page: Which One Do You Need?
The three most conflated terms in early-stage product development are MVP, prototype, and landing page. Founders use them interchangeably, build them at the wrong stage, and then wonder why the artifact they produced didn't give them the information they needed.
They answer different questions. Building the right one is building the one whose question you most need answered right now.
Here is the precise definition of each, what it answers, and when you need it.
The Landing Page
What it is: A single web page describing a product that may or may not exist, with a way to capture contact information from interested visitors.
What question it answers: "Does this description of the product, shown to strangers who have the problem, generate enough interest for them to give me their email address?"
This is a test of message-market fit. Not product-market fit. Not user experience fit. Purely: does the value proposition land with the target audience? Does the specific way you've described the problem and the promised solution resonate enough to generate a real behavioral response (signing up) from a person with no prior relationship with you?
What it doesn't answer: Whether the product will actually work. Whether users will stick around after the initial interest fades. Whether the experience will be intuitive. Whether users will pay. These questions are answered by different artifacts.
What it costs to build: 1-3 days of part-time work. No-code tools (Carrd, Webflow, Framer) reduce it further. A domain, an email capture form, and a connected email tool (Beehiiv, MailerLite) are the only required infrastructure.
When you need it: Before you've validated demand. Before you've built anything. Before you know whether anyone wants what you're proposing to build. If you're at the stage where your primary question is "is there a market for this?" -- a landing page is the right artifact.
The signal that tells you it worked: A cold traffic conversion rate above 8% from relevant communities (people who match your target customer profile and found the page organically or through targeted distribution). Below 5%: the headline or the concept isn't resonating. Above 12%: strong resonance, proceed with confidence.
When to skip it: When you have so much direct access to your target customers through an existing community, network, or platform that you can validate demand through direct conversations and commitments rather than anonymous page visits. Some products -- particularly those built for closed professional communities -- can collect pre-commitments from named people without a public landing page.
The Prototype
What it is: A simulated version of the product's user experience -- interactive screens that look and feel like the product but have no real functionality behind them. Built in a tool like Figma, Framer, or Marvel.
What question it answers: "Does the user experience I've designed feel intuitive, logical, and useful to a real user who navigates through it with tasks in mind?"
A prototype tests UX assumptions. It allows you to watch a real person try to accomplish a specific task in your designed interface and observe where they get confused, what they expect to find where, and whether the flow you've designed matches the mental model your user brings.
What it doesn't answer: Whether users will actually use the product consistently over time (a simulated experience doesn't test real behavior). Whether the product will work technically. Whether users will pay. These require different artifacts.
What it costs to build: 1-3 weeks of part-time work for a competent interface designer; longer if you're learning the tools. Figma is free for basic use. The main cost is time and design skill.
When you need it: When you have demand validated (the landing page worked), you have a clear idea of the core user workflow, and the primary risk remaining is whether the UX you've designed is intuitive for your target user -- before you invest the weeks of development time required to build the real thing.
When to skip it: Most indie hackers skip the prototype step entirely, and for many products this is correct. If your product is a relatively straightforward workflow tool without complex interaction patterns, the user experience risk is low enough that you can build the MVP directly and iterate from real usage. If you're building something where the interaction design is the core differentiation -- a design-forward consumer app, a complex data visualization, a multi-step workflow with novel patterns -- a prototype is worth the investment before you build.
The honest observation: The prototype is the validation artifact most frequently suggested by product designers and most frequently skipped by indie hackers, and both groups are often right given their respective contexts. Product designers work on products where the interaction design risk is high. Indie hackers often build products where the interaction design is conventional and the risk lies elsewhere.
The MVP (Minimum Viable Product)
What it is: A working version of the product that does the core thing -- the minimum set of features required to deliver the primary value -- well enough for a real customer to use it in the context of their real work.
What question it answers: "Do real people, using this product in their actual workflow, get enough value from it to keep using it and pay for it?"
This is the test that validates product-market fit at the usage level. The landing page showed you that the description resonated. The MVP shows you whether the product itself delivers the value you promised.
What it doesn't answer: Whether the product will scale to 10,000 users. Whether the architecture is the right long-term architecture. Whether all the features users might eventually want are present. These questions are answered by later products.
What it costs to build: Variable, but for a solo developer using modern tooling (Next.js + Supabase + Stripe), a true MVP for a focused micro-SaaS product should be achievable in 4-12 weeks of part-time work. The longer the timeline, the more likely scope has expanded beyond what "minimum viable" actually requires.
The most common MVP mistake: Building too much. The "minimum" in MVP is regularly violated by founders who add features because customers mentioned wanting them in interviews, because they feel the product needs more before it's credible, or because they're using building as a delay mechanism. An MVP that takes six months to build is usually not an MVP. It's a full product with an MVP label.
The test for minimum: Can a user accomplish the primary task -- the task that constitutes the core value -- with what exists? If yes, that's the MVP. If no, keep building. If yes but with some awkward workarounds, that's still an MVP.
When you need it: After demand is validated (landing page worked) and after UX direction is established (either through a prototype or through customer conversations that gave you enough context to design confidently). The MVP is what you build when the question has shifted from "does anyone want this?" and "will people understand how to use this?" to "does this actually work in practice?"
Choosing the Right One for Your Stage
The decision is straightforward when you map it to the question you most need answered:
| Your primary question | The right artifact |
|---|---|
| "Is there a market for this?" | Landing page |
| "Does my UX design work for my users?" | Prototype |
| "Does the product deliver real value?" | MVP |
If you're uncertain which question is your primary question, use this sequence:
Step 1: Do you have validated demand from strangers (cold traffic, not just friends)? If no → landing page. If yes → Step 2.
Step 2: Does your product have unusually complex interaction patterns that represent a significant design risk? If yes → prototype. If no → Step 3.
Step 3: Build the MVP.
The sequence is not always followed. Founders sometimes build an MVP before validating demand (building without a landing page), build a prototype before validating demand (design work before market research), or skip directly from landing page to MVP without ever building a prototype (usually appropriate for simpler products).
The most expensive wrong sequence: building the MVP before the landing page. This produces a working product whose message-market fit may be wrong -- meaning the copy and positioning don't resonate with the target customer -- and which requires the founder to discover this through disappointing launch traffic rather than through a two-day landing page experiment run three months earlier.
The Special Cases
When a landing page is the MVP: For products where the core value is information, curation, or community, the landing page may itself be the minimum viable product. A newsletter, a job board, a curated resource -- these can be "launched" through a landing page that begins collecting subscribers before the product is meaningfully different from the page itself.
The Wizard of Oz MVP: A manually powered MVP is a working product experience for the user that is powered by human effort behind the scenes rather than software. The founder does manually what the software will eventually do automatically. This is a legitimate MVP form for validating that the product delivers value before investing in automation. It's slower than software for the founder, but faster than building the software before validating value.
The concierge MVP: Doing the service for a small number of customers manually -- doing their invoicing, doing their scheduling, managing their client communications -- is a form of MVP that produces deep operational knowledge while validating willingness to use the service. Often more valuable than software at this stage.
The Artifact for Your Question
The single most useful reframe for this decision:
Every artifact exists to answer a question. Before you build anything, write down the most important question you need answered about your idea right now.
If the question is about demand, interest, or whether the problem resonates: landing page.
If the question is about user experience, interaction design, or workflow logic: prototype.
If the question is about whether the product actually delivers value in practice: MVP.
The artifact that answers your question at the lowest time cost is the right one.
Build that one. Answer the question. Then build the next one.
Ready to validate your idea?
Start using WarmLaunch today to grow your waitlist.