10,247 founders read this month Updated 2026-06-08 Cited · verified sources Independent · No VC
Startup Foundations · The Foundations
Read time 15 min read Published 2026-06-08

What Is an MVP? The 2-Week Founder Guide to Building One

Most founders build MVPs that are too big, take 6 months, and teach them nothing. This guide reframes the MVP as a question, not a product, with the 5 MVP types every founder should know (landing page, concierge, Wizard of Oz, single-feature, no-code), the exact 14-day playbook to ship one, examples from Airbnb, Dropbox, Buffer, and Zappos, and the pass/fail criteria that separate real validation from wishful thinking.

What Is an MVP? The 2-Week Founder Guide to Building One
The 60-second answer

An MVP (minimum viable product) is the smallest version of a product that lets you test one critical assumption with real users. The goal is not a product. It is a learning loop. You build it in days or weeks, not months, using whatever tools let you skip writing code (landing pages, manual processes, no-code apps). If it proves demand, you build the real thing. If it does not, you saved six months and your savings.

82% of startups die from building things nobody wanted, according to CB Insights' largest post-mortem analysis. The MVP, the minimum viable product, was named in 2011 by Eric Ries in The Lean Startup for exactly one reason: to stop founders from building things nobody wanted. Fifteen years later, founders are still building MVPs that take six months and teach them nothing.

The reason is not laziness. It is confusion. "Minimum" sounds simple. "Viable" sounds judgemental. So founders default to building everything "just in case." Six months later they have a product, no customers, and no money left.

This guide reframes the MVP as a question, not a product. By the end you will know exactly what to build, what to skip, and how to ship it in 14 days, with examples from Airbnb, Dropbox, and Buffer, plus the exact tool stack to use today.

What Is an MVP? A Plain Definition

An MVP (minimum viable product) is the smallest, cheapest version of an idea you can put in front of real customers to test whether they will pay for it. That is the entire definition. Anything more is mission creep.

The term was coined by Frank Robinson in 2001 but popularised by Eric Ries in his 2011 book The Lean Startup, which has since sold over a million copies and rewired how Silicon Valley thinks about product development. Steve Blank, the godfather of customer development whom Ries studied under, defines it more bluntly: "The MVP is the minimum feature set required to learn from early customers". Notice the word. Learn. Not sell. Not scale. Learn.

An MVP IS

A learning experiment with real users to validate one risky assumption

An MVP IS NOT

A smaller version of the final product, a beta, or a v1 launch

THE GOAL

Maximum learning for the minimum amount of time and money spent

Here is the test. Ask yourself: "If this MVP succeeds, what specifically have I learned?" If you cannot finish the sentence in 10 seconds with something measurable, you are not building an MVP. You are building a product on faith and calling it lean.

Why Most MVPs Are Still Too Big

The dirty secret of MVPs is that almost nobody actually builds one. They build a product, spend three to six months on it, call it an MVP, and then act surprised when the lesson it teaches them ("nobody wants this") arrives too late to do anything about.

The typical "MVP" goes like this. Founder has idea. Founder makes a list of features. Founder removes the obviously unnecessary ones. Founder builds the remaining 20 features over four months. Founder launches. Crickets. Founder spends another month doing "marketing" because the build "must be fine, look at all the features."

What an MVP should actually look like. Founder has idea. Founder writes the riskiest assumption as one sentence ("I believe freelance writers will pay $20/month for a tool that auto-formats invoices in Stripe"). Founder builds the cheapest possible thing that tests only that assumption (a landing page with a fake "Subscribe for $20/mo" button). Founder gets 5 sign-ups, 50, or 500 in two weeks. Founder now has a real answer.

Most "MVPs"
  • Built over 3 to 6 months
  • 15 to 30 features
  • Tests "will it work technically"
  • Custom auth, dashboard, settings
  • Costs $5k to $50k in time and tools
  • Teaches you almost nothing
An actual MVP
  • Built in 1 to 4 weeks
  • 1 core promise, 0 to 3 features
  • Tests "will anyone pay for this"
  • No code or no-code, manual fulfilment
  • Costs under $500
  • Teaches you exactly one thing fast

This is the mental shift. You are not building a product. You are buying information. The minimum is whatever buys the most information for the least time. A landing page that gets 47 paid pre-orders in 10 days is more useful than a polished SaaS that nobody signs up for, because the landing page told you something true. The SaaS only told you that you can write code, which you already knew.

If you have not validated the idea at all yet, start with our step-by-step micro-SaaS idea validation guide first. The MVP comes after validation, not before.

The 5 Types of MVPs (With Real Examples)

The biggest decision in MVP work is not what to build. It is which type to build. Each type tests a different question, at a different cost, with a different signal quality. Pick the wrong type and your data is worthless. Pick the right one and you will know more in two weeks than most founders learn in a year.

Here are the five types every founder should know, with the actual companies that used them.

1. The Landing Page MVP

What it is: a one-page website that describes a product that does not exist yet, with a clear price and a sign-up or pre-order button. Run paid ads or post in communities to drive traffic. Measure the click-to-sign-up rate.

Real example: Buffer. In 2010, Joel Gascoigne shipped a two-page MVP. Page one explained the product. Page two showed the pricing. Visitors who clicked "Plans and Pricing" saw a message saying the product was not built yet but they could leave their email. Enough did that Joel built it. Buffer now does over $20M in ARR.

Tests: Whether the value proposition is interesting enough to convert traffic. Cost: Under $100 with Carrd or Webflow plus $50 in ads. Time to build: 2 to 5 days.

2. The Concierge MVP

What it is: you manually deliver the service one customer at a time, no software, doing every step by hand. The customer thinks they bought a product. You are the product.

Real example: Airbnb. In 2007, Brian Chesky and Joe Gebbia photographed their own apartment, listed it on a homemade site, and personally handled every booking. Later, when they expanded to other hosts, they flew to each city to photograph apartments themselves. The "platform" was three guys with cameras for the first 18 months.

Tests: Whether the experience itself creates value, before any product exists. Cost: Your time. Time to build: 1 to 3 days to set up, then ongoing manual delivery.

3. The Wizard of Oz MVP

What it is: it looks like an automated product to the customer, but behind the scenes you are doing everything manually. Customer cannot tell the difference.

Real example: Zappos. In 1999, Nick Swinmurn wanted to know if anyone would buy shoes online. Instead of building inventory, warehouses, and logistics, he photographed shoes at local stores. When someone ordered, he physically walked back to the store, bought the pair, and shipped them. He lost money on every sale, intentionally, because each one was paid market research. Zappos sold to Amazon for $1.2B.

Tests: Whether the demand actually exists at the projected price. Cost: Under $500 typically. Time to build: 1 week.

4. The Single-Feature MVP

What it is: instead of building 10 features at 30% quality, you build one feature at 95% quality. That feature is the entire product. Everything else gets cut.

Real example: Dropbox. Drew Houston could not afford to build the full sync engine before he knew anyone wanted it. So he made a three-minute video showing exactly how Dropbox would work, posted it on Hacker News, and watched his beta waitlist explode from 5,000 to 75,000 overnight. The video was the MVP. The product came after the waitlist proved demand.

Tests: Whether the core value alone justifies the price. Cost: Variable, often $0 to $1,000. Time to build: 1 to 3 weeks.

5. The No-Code MVP

What it is: you stitch together off-the-shelf tools (Webflow, Tally, Airtable, Stripe, Zapier) to build a working product without writing a single line of code. Customers use it the same way they would use a "real" SaaS.

Real example: Comet Docs and dozens of profitable micro-SaaS businesses. Tools like Bubble, Glide, and Softr now let solo founders ship functional MVPs in days. The Indie Hackers community is full of $5k to $50k MRR products that were built entirely no-code.

Tests: Whether the full user experience converts. Cost: $50 to $200/month in subscriptions. Time to build: 1 to 4 weeks.

MVP TypeSetupCostBest for testing
Landing Page2 to 5 daysUnder $100Whether the value prop interests anyone
Concierge1 to 3 daysYour timeWhether the experience creates value
Wizard of Oz1 weekUnder $500Whether demand exists at your price
Single Feature1 to 3 weeks$0 to $1,000Whether the core feature alone is worth paying for
No-Code1 to 4 weeks$50 to $200/moWhether the full experience converts

MVP vs Prototype vs Proof of Concept (Common Confusion)

These three terms get mixed up constantly, including by experienced founders. They are not the same thing and using them interchangeably is how you end up building the wrong thing for six months.

Proof of ConceptPrototypeMVP
Question it answersIs this even technically possible?How will this feel to use?Will anyone actually pay for this?
AudienceInternal engineersInternal team or select usersReal paying customers
What you shipA code spike or technical docA clickable demo or mockupA working product, however ugly
TimelineDays1 to 2 weeks2 to 4 weeks
Success looks like"Yes, the algorithm works""Yes, users understand it""Yes, X people paid for it"

Here is the simplest way to remember the difference. A proof of concept proves the engineering. A prototype proves the design. An MVP proves the business. Most founders skip the PoC and prototype stages (which is fine for non-technical products) and go straight to the MVP. That is the right move, as long as you know that an MVP is fundamentally about demand, not about whether you can build the thing.

How to Build an MVP in 14 Days (Step-by-Step)

This is the operational playbook. Two weeks, five steps, one shippable MVP. The timeline assumes you are working on it 3 to 5 hours a day. If you can only spare an hour, double the calendar but keep the steps.

1

Days 1 to 2: Write Your Riskiest Assumption in One Sentence

Every idea is a stack of assumptions. Most of them are safe. One or two will kill your business if they are wrong. Find the riskiest one and write it as a single sentence using this template:

"I believe [specific type of person] will pay [specific amount] for [specific outcome] to solve [specific problem]."

Example: "I believe freelance copywriters earning $50k+ will pay $29/month for a tool that auto-generates invoice reminders connected to their Stripe account."

Vague assumptions produce vague MVPs. The more specific you are here, the easier every following decision becomes.

2

Days 3 to 4: Pick the MVP Type That Tests It Cheapest

Match your assumption to the right MVP type. Use this quick decision tree:

  • Testing whether the value prop is interesting? Landing Page MVP.
  • Testing whether the manual experience creates value? Concierge MVP.
  • Testing whether demand exists at your price? Wizard of Oz MVP.
  • Testing whether the core feature alone is enough? Single Feature MVP.
  • Testing the full automated experience? No-Code MVP.

Picking the wrong type is the most common reason an MVP teaches you nothing. A landing page cannot tell you if people will actually use a product. A no-code MVP cannot tell you if the value prop is interesting at the top of funnel. Match the type to the question.

3

Days 5 to 8: Build It Using No-Code or Manual Fulfilment

You do not need a developer for any of this. The standard solo-founder MVP stack in 2026:

  • Landing page: Carrd ($19/year), Framer (free tier), or Webflow ($14/mo)
  • Forms and signup capture: Tally (free), Typeform (free tier)
  • Payments: Stripe Checkout or Lemon Squeezy (no setup fees, 5% per transaction)
  • No-code apps: Bubble, Softr, Glide
  • Backend automation: Zapier, Make (formerly Integromat)
  • Email: ConvertKit (free up to 1k subscribers), Loops (clean Stripe integration)

This stack runs about $30 to $100 a month total. Skip beautifying it. Founders waste days picking colours when the only thing that matters is whether someone clicks the button.

4

Days 9 to 10: Set the Pass/Fail Bar Before You Launch

This is the step almost every founder skips and the one that separates real MVPs from glorified hobbies. Before you put your MVP in front of anyone, write down the number that means "yes" and the number that means "no."

Common pass criteria by MVP type:

  • Landing Page: 30+ signups per 1,000 visitors, or 10+ pre-orders in 14 days
  • Concierge: 5+ paying customers who would buy again at full price
  • Wizard of Oz: 10+ completed orders, repeat rate above 20%
  • Single Feature: 100+ active users in week 1, 30%+ week 2 retention
  • No-Code: 20+ signups with 5+ paying within 14 days

If you skip this step, you will rationalise any result. You always do. Set the number while you can still be honest with yourself.

5

Days 11 to 14: Launch to a Small Audience, Measure, Decide

You do not need Product Hunt. You need 200 real humans who match your target customer. Three places to find them fast:

  • Communities: 2 to 3 niche subreddits, Indie Hackers, your industry's Slack groups
  • Direct outreach: 50 personal DMs or emails to ideal customers from LinkedIn
  • Paid traffic: $50 to $200 in targeted ads (Facebook or Reddit) to a cold audience

Watch the data for 4 to 7 days. Then compare to the pass/fail bar you set on Day 10. No rationalising. The number is the number.

That is the playbook. Two weeks, real data, a clear yes or no. For the next step (finding your first paying users at scale), our guide on how to get your first 10 SaaS customers picks up exactly where this leaves off.

How to Know If Your MVP Worked

The result of an MVP is never "the product worked." It is always one of four outcomes. Knowing which one you are in tells you what to do next.

Outcome 1

Persevere

You hit or beat your pass bar. The assumption is validated. Now build the real product around what worked. The MVP becomes the foundation. This is the rarest outcome.

Outcome 2

Pivot

You missed the bar, but something unexpected got traction. A different audience, a different feature, a different price point. Rewrite the assumption sentence and run a new MVP. Slack pivoted from a failed game. So can you.

Outcome 3

Polish

You came close to the bar (within 30%). The problem is presentation, not product. Try a better landing page, sharper copy, different audience. Run for another 14 days before declaring failure. Sometimes the experiment is right and the marketing was wrong.

Outcome 4

Kill

You missed the bar badly and nothing surprising emerged. This is the success people forget to celebrate. You spent 2 weeks instead of 6 months learning your idea was wrong. Kill it. Pick a new one. Onwards.

If your MVP succeeded and you are wondering what comes after the validation phase, the next milestone is product-market fit, measured by the Sean Ellis 40% test and retention curves. That is a different game with different rules.

5 MVP Mistakes That Kill Startups Before They Start

Every wrong MVP looks slightly different. The mistakes underneath them are usually the same five. I have watched founders make every one of these. Some of them, more than once.

01

Building features instead of testing assumptions

Symptoms: feature list before assumption sentence, more than 3 things in v1, the words "users will need." You are not building an MVP. You are building a product on autopilot. Start over with the assumption sentence.

02

Skipping "are people willing to pay"

Free signups, waitlist counts, and survey "interest" mean almost nothing. The only signal that matters is money changing hands or a credit card being entered. Even a $5 pre-order beats 10,000 free emails. If you cannot ask for money, you have not tested anything important.

03

Confusing "minimum" with "embarrassing"

Ries famously wrote that if you are not embarrassed by your MVP, you launched too late. True for technical polish. Not true for the value proposition. The promise should be sharp. The execution can be ugly. Founders flip this and end up shipping a beautiful product that promises nothing memorable.

04

Choosing the wrong MVP type for the assumption

The classic: testing whether a "platform" idea works by running ads to a landing page. A landing page cannot tell you if a marketplace gets liquidity. It can only tell you if the headline interests people. Match the type to the question being asked.

05

Never setting a kill criterion

Without a pass/fail bar set before launch, every result becomes "promising." Founders run MVPs for months without a clear answer because they never decided what no would look like. Decide upfront. Honour the number.

The MVP Toolkit (Tools Founders Actually Use)

You do not need a complicated stack. These are the tools profitable solo founders actually use to ship MVPs in 2026, organised by what they replace.

Landing pages
  • Carrd ($19/yr)
  • Framer (free tier)
  • Webflow ($14/mo)
Forms and surveys
  • Tally (free)
  • Typeform (free tier)
  • Google Forms (free)
Payments
  • Stripe Checkout (free, 2.9%)
  • Lemon Squeezy (5% per sale)
  • Gumroad (10% per sale)
No-code apps
  • Bubble (full SaaS)
  • Softr (Airtable + UI)
  • Glide (mobile apps)
Automation
  • Zapier (basic)
  • Make (advanced)
  • n8n (self-hosted)
Email
  • ConvertKit (free to 1k)
  • Loops (Stripe-native)
  • Beehiiv (free tier)

The full breakdown lives in our companion guide on the best no-code tools for micro-SaaS in 2026, with pricing and side-by-side comparisons.

One last reframe before you build. The minimum viable product is not a product you ship. It is a question you ask. If you finish your MVP and cannot point at a measurable answer you did not know before, you did not build an MVP. You built a product nobody asked for. Always lead with the question. The product builds itself when the question is clear.

Frequently Asked Questions

MVP stands for minimum viable product. It is the smallest version of a product that lets a founder test one critical business assumption with real users. The term was popularised by Eric Ries in his 2011 book The Lean Startup.

A focused MVP should ship in 2 to 4 weeks. If yours is taking 3 or more months, you are not building an MVP, you are building a product before validating it. Either narrow the scope or pick a cheaper MVP type (landing page, concierge, Wizard of Oz).

A prototype tests how a product will feel to use. An MVP tests whether real customers will pay for it. Prototypes stay internal, MVPs go to market. A prototype answers a design question. An MVP answers a business question.

No. Many of the most successful MVPs in history used no code at all. Dropbox used a video. Airbnb used photos and Craigslist. Zappos used local shoe stores. You can build a credible MVP today with Carrd, Tally, Stripe, and Zapier for under $100.

Most MVPs should cost under $500 in tools and zero developer hours. The real cost is time, typically 40 to 80 focused hours over 2 weeks. If your MVP plan requires hiring developers or raising money, you are not building an MVP.

Set a pass/fail criterion before you launch. Common ones: 10 paying customers in 14 days, 100 email signups with 30% open rate, or a measured willingness-to-pay above your target price. Anything else is rationalising results after the fact, which every founder does if they have not set the number in advance.

Aziz Chaabane, founder and editor of Groundwork
Written by

Aziz Chaabane

Founder & Editor, Groundwork

Aziz researches and writes every Groundwork guide personally. Each piece is built from primary sources — IRS, SBA, Federal Reserve, BLS, and direct founder interviews — and updated as the evidence changes. No recycled advice, no affiliate-driven recommendations, no AI-generated filler.

Live · 10,247 readers this monthVol. IIIEst. 2026
Imagery · Public DomainIndependent · No VC
Groundwork
The Index Finance AI & Tools Marketing Startup About
Subscribe Free
Theme