Minimum Viable Product Examples: 12 MVPs, What They Actually Tested, and What You Can Steal

TL;DR: Every list of famous MVP examples tells you what Dropbox, Airbnb, and Uber built first. Almost none tell you what hypothesis each MVP was designed to test, what the founders expected to learn, and what they actually discovered that changed everything. That is what this guide does. Twelve MVPs consumer and B2B, funded and bootstrapped, code-heavy and no-code dissected for the one riskiest assumption each founder was trying to kill. Startups with a functional MVP and early user data are 3× more likely to secure pre-seed funding (We Are Presta 2026). Focused MVPs reduce initial development costs by up to 60% (We Are Presta 2026). The pattern across every example: one narrow user, one painful problem, one validation question answered before spending more.

Before the Examples: The 5 MVP Types

Not every MVP requires a codebase. The right MVP type for your situation depends on what you need to validate and how quickly.

The right sequence for most B2B SaaS founders: landing page → concierge → single-feature build. Never jump straight to a full product.

The 12 Examples

1. Dropbox: The Explainer Video MVP

What they built: A 3-minute screen recording video demonstrating a product that did not exist yet. No code. No working software.

The riskiest assumption: “People have a real problem syncing files across devices and will sign up for a waitlist solution they have never used.”

What they tested: Not whether the technology worked (it did not exist). Whether anyone cared enough about the problem to take action, sign up, give an email, express intent.

What happened: The Dropbox waitlist grew from 5,000 to 75,000 overnight after the video went live on Hacker News. Drew Houston had his answer before writing a single line of production code.

The lesson: If your product’s core value can be demonstrated on video, build the video before the product. The validation cost is $1,000. The alternative, building the product first to see if anyone cares, costs $60,000 and 12 weeks.

What to steal: For any product where the “aha moment” is demonstrable in a screen recording, make the video first. Post it where your target users already are. Measure signups, not views.

2. Airbnb: The Concierge MVP

What they built: Brian Chesky and Joe Gebbia photographed their own apartment, posted it on a basic website, and rented out air mattresses on their floor to conference attendees in San Francisco. They did not build a marketplace. They hosted guests themselves.

The riskiest assumption: “Strangers will pay to sleep in someone else’s home, and homeowners will agree to host them.”

What they tested: Both sides of a two-sided marketplace simultaneously. The demand (guests willing to pay) and the supply (hosts willing to participate), both with real money, real stays, real feedback.

What happened: They confirmed both sides. The supply problem (homeowners hesitant to host strangers) was the harder assumption, and they learned it by experiencing it themselves, which led to the breakthrough of professional photography for listings, one of Airbnb’s most important early product decisions.

The lesson: For two-sided marketplace products, the concierge approach validates both sides simultaneously without building the matching infrastructure. The most valuable thing you learn is not “does this work?”, it is which side is harder to acquire.

What to steal: If you are building a marketplace, spend two weeks manually matching supply and demand yourself before writing any code. The friction you experience manually is the problem your product must eventually solve.

3. Zappos: The Wizard of Oz MVP

What they built: Nick Swinmurn photographed shoes at local stores, posted them on a basic website, and when someone placed an order, he went to the store, bought the shoes, and mailed them himself. No inventory. No warehouse. No fulfilment system.

The riskiest assumption: “People will buy shoes online without trying them on first.”

What they tested: Purchase intent with real money. Not survey responses. Not “would you buy.” Actual orders.

What happened: People bought shoes online. The hypothesis was validated. Swinmurn built the fulfilment infrastructure only after he knew it was worth building.

The lesson: The Wizard of Oz approach works when the riskiest assumption is willingness-to-pay and the “automation” is not visible to users. The infrastructure cost (the warehouse, the inventory system, the logistics) is only worth building after demand is proven.

What to steal for B2B SaaS: Before building the automated workflow, offer the service manually to 5 clients. Use spreadsheets, Zapier, your own time. If clients pay and come back, build the automation. If they do not return, the problem was not as painful as assumed, and you have not spent $80,000 learning that.

4. Buffer: The Landing Page MVP

What they built: Joel Gascoigne built a two-page website. Page 1: “Buffer helps you share things smarter on Twitter.” Page 2 (reached by clicking “Plans and Pricing”): “Buffer is not ready yet. Leave your email to be notified.” No product. No code behind the button.

The riskiest assumption: “People who manage social media for a living will pay for a tool that schedules tweets in advance.”

What they tested: Demand, specifically, willingness to progress through a pricing gate before the product existed.

What happened: People left their emails. Gascoigne added a real pricing page to test price sensitivity. People left their emails at the paid tier too. He had validated demand and price before writing a single line of product code.

The lesson: A landing page MVP with a pricing gate reveals whether someone is willing to pay, not just whether they are interested. “Free email signup” validates curiosity. “Clicks through a pricing page” validates intent.

What to steal: Build the pricing page before the feature. If people drop off at pricing, the price is wrong or the value is unclear. If people click through and express intent, the price point is viable. This test costs $500 and 3 days.

5. Slack: The Single-Feature Build from a Failed Product

What they built: Stewart Butterfield and his team were building a game called Glitch. The game failed. The internal communication tool the team built for themselves during Glitch development did not fail, it worked better than anything they had tried before.

The riskiest assumption (for Slack): “The communication patterns that made our 20-person game studio more effective will work for other teams.”

What they tested: They gave early access to a small number of other companies and watched whether usage sustained without the novelty wearing off.

What happened: Usage sustained. Message volume grew. Users described it as the product they had been looking for without knowing it. Slack launched publicly in August 2013, signed up 8,000 companies on day one, and reached 135,000 users in 24 hours.

The lesson for founders: Sometimes the MVP is already built, it just exists inside your own organisation. The internal tools a team builds to solve its own problems are often a better signal of market need than anything a founder can imagine from scratch. Slack is not a unique story. Many successful SaaS products started as internal tools (HubSpot, GitHub, Atlassian products).

What to steal: If you have built an internal tool that your team genuinely prefers over commercial alternatives, that preference is a hypothesis worth testing with external users. Before pivoting to build something new, ask whether the tool you already use every day is the product.

6. Instagram: The Scoped Pivot MVP

What they built: Kevin Systrom built an app called Burbn, a check-in app with photos, plans, points, and social features. It was a full-featured product. It failed to find users.

The riskiest assumption (for Instagram): “Photo sharing with filters, extracted from Burbn as a single feature, is what users actually want.”

What they tested: One feature, stripped from a failed product, shipped as a standalone app. They removed everything except: take a photo, apply a filter, share it.

What happened: The single-feature version launched October 6, 2010. One million users in the first two months. Facebook acquired Instagram for $1 billion 18 months after launch.

The lesson: A failed product can contain a successful MVP. The feature that users were actually using inside a product that was otherwise failing is a testable hypothesis. Stripping everything else away and shipping the one thing that worked is one of the most reliable MVP patterns in SaaS.

What to steal: If your product has users who return for one specific feature while ignoring everything else, that feature is your real product. Build the version that does only that one thing, exceptionally well, and remove the rest.

7. Uber: The Geographic-Constraint MVP

What they built: UberCab launched in San Francisco only, with black cars only, for a small number of beta users invited by SMS. No surge pricing. No driver marketplace. No app rating system. No cash payments. Black cars, one city, invitation only.

The riskiest assumption: “People will pay a premium to summon a car from their phone, even in a single city with limited availability.”

What they tested: Willingness to pay a premium for convenience in a tightly constrained geography, with a deliberately limited supply to manage the logistics manually.

What happened: Beta users did not just use it, they demanded it. The feedback was overwhelmingly “when is this coming to my city?” rather than “I don’t find this useful.” Uber expanded city by city, each expansion as constrained as the first, until the logistics were proven.

The lesson for B2B: The geographic or vertical constraint is underused in B2B SaaS. Most founders launch broadly when they should launch narrowly: one industry, one geography, one company size. The constrained launch produces higher-quality learning, more manageable support load, and a clearer path to referral.

What to steal: Define the smallest geography, vertical, or customer segment that would make the business worth validating. Launch there first. Expand only after you have product-market fit signals in that constrained segment.

8. A B2B Workflow Tool: The Spreadsheet MVP

The pattern (composite of common B2B MVP stories): A founder identifies that a specific operations workflow, invoice reconciliation, compliance tracking, candidate screening, is done manually with spreadsheets by most companies in a target vertical. Before building any software, the founder:

1. Builds a shared Google Sheet that does the workflow more efficiently than the unstructured approach
2. Offers to manage it for 5 companies manually as a service
3. Charges $500/month for the managed service
4. Builds automation (Python scripts, Zapier, simple web app) only when the manual process is validated and paying

The riskiest assumption: “Companies in this vertical will pay a recurring subscription for software that automates this workflow.”

What they tested: First, whether the workflow is painful enough that companies will pay someone else to manage it. Then, whether the automation is reliable enough to remove the human.

The lesson: For B2B SaaS targeting a known manual workflow, the Wizard of Oz / concierge approach is almost always the right first step. Build the spreadsheet. Manage it for 5 clients. Charge from day one. Automate only what clients are paying for and returning for.

What to steal: If your target customer does the workflow manually today, offer to do it manually for them before building software. The insights from manual delivery, every edge case, every exception, every thing the software will need to handle, are worth more than the $5,000 you save by going straight to code.

9. Spotify: The Rights-Constrained MVP

What they built: Spotify launched in 2008 with a desktop-only app, invite-only access, and music rights covering only a small library compared to what they eventually licensed. The streaming quality was a deliberate MVP decision, they prioritised perceived instant playback (local cache tricks to make it feel instant) over full catalogue.

The riskiest assumption: “If streaming feels instant, users will prefer it over owning music files, even with a limited catalogue.”

What they tested: The core UX hypothesis: does instant streaming feel better than local files, enough to change behaviour? Not “can we license all music” (they could not yet). Just: does the experience win?

What happened: It did. The constraint (invite-only, limited catalogue) created scarcity that drove word-of-mouth. The UX hypothesis was proven, and Spotify used those results to negotiate expanded licensing with record labels.

The lesson: Constraints are not always a compromise. In Spotify’s case, the invite-only constraint was a growth mechanic. The catalogue constraint forced the team to prove the UX hypothesis with a small dataset before investing in licensing all music. Artificial scarcity and constrained access can make an MVP more interesting, not less.

What to steal: If your product requires rights, partnerships, or integrations that are hard to acquire at scale, design the MVP around the partnerships you can acquire now and prove the UX hypothesis with that constrained dataset. Expand rights/partnerships once the UX case is proven.

10. Amazon: The Bookstore First MVP

What Jeff Bezos built: Amazon launched as an online bookstore. Not an online marketplace. Not an everything store. Books, because books are easy to ship (flat, uniform, durable), have high SKU count (proof of selection), and buying decisions do not require physical inspection.

The riskiest assumption: “People will buy products online with a credit card without seeing them first.”

What they tested: The general proposition that online retail is viable, using books as the category most likely to produce a purchase without physical inspection. If people would buy a book online without inspecting it, they would eventually buy other things.

What happened: They would. Amazon expanded from books to music, to electronics, to everything. Each category expansion was effectively a new MVP hypothesis tested against an existing user base.

The lesson: The product category of the MVP is not the product category of the company. Bezos was not building a bookstore. He was building a belief that people would buy things online. Books were the minimum viable way to test that belief.

What to steal: If your vision is broad (a marketplace, a platform, a category-defining product), find the narrowest, clearest version of the core hypothesis and test that first. The MVP category is not the company’s destiny, it is the experiment that proves the engine.

11. Groupon: The Concierge Marketplace MVP

What they built: Groupon started as The Point, a social activism platform where users coordinated around causes. When a pizza coupon campaign on The Point was the most popular thing users ever did, founder Andrew Mason redirected.

The first Groupon MVP: a WordPress blog. Mason offered 50% off a $10 Motel One pizza slice, one deal per day, via email to the people in his office building. He manually emailed the PDF coupon to everyone who signed up. No software. No fulfilment system. No merchant onboarding flow.

The riskiest assumption: “Local merchants will pay to reach customers via time-limited group offers.”

What they tested: Merchant willingness to discount in exchange for volume, and customer conversion on a group buying model.

What happened: Both sides worked. Groupon grew from one WordPress blog to 35 million subscribers in 35 countries within 2 years. At the time, it was the fastest-growing company in history.

The lesson: A WordPress blog and manual emailing proved a business model that would reach a $1.35 billion IPO (2011). The concierge approach works at company-defining scale. The question is not “is this too manual?”, it is “is this validating what I need to validate?”

What to steal: If your product depends on a two-sided market or a merchant/supplier relationship, validate the supplier side manually (cold outreach, phone calls, personal offers) before building any onboarding software. The friction in manual onboarding is the exact friction your product must eventually eliminate.

12. Notion: The “Build It for Yourself” MVP

What they built: Notion’s founders, Ivan Zhao and Simon Last, built the first version of Notion as the tool they wanted to exist for themselves, a single tool that combined docs, wikis, spreadsheets, and databases. They used it internally for years while it remained buggy and invitation-only.

The riskiest assumption: “Knowledge workers will switch from multiple specialised tools (Google Docs + Confluence + Airtable + Trello) to one flexible workspace, even if the flexible workspace does each thing slightly less well.”

What they tested: Their own sustained use. If the founders who built the tool preferred it to commercial alternatives in their own daily work, that preference was worth testing externally.

What happened: Notion launched publicly in 2018 (years after the internal MVP), reached 4 million users by 2020, and was valued at $10 billion in 2021 at a $275M Series C. The “build it for yourself” hypothesis, tested for years internally, proved durable.

The lesson: The longest-running validation periods sometimes produce the most defensible products. Not every MVP needs to ship in 8 weeks. Notion spent years as an internal tool before launching. The validation was real, it was just the founders, not external users, providing the signal. When the product is genuinely used by its creators every day in preference to alternatives, that is a form of evidence worth weighting.

What to steal: If you are solving a problem you personally experience, your own daily use is a data point. Not the only data point, but the first one. Track your own usage, your moments of frustration, and your moments of delight. They are the first version of the qualitative feedback loop that will inform your product decisions.

The 5 Hypotheses Every MVP Should Test (And Which Example Tests Each)

Most MVPs test only hypothesis 1 (demand). The companies that reach product-market fit fastest test hypotheses 2 and 3 simultaneously, finding out whether the workflow actually fits and whether users will pay before building the full product.

What These MVPs Have in Common

Across all 12 examples, five patterns repeat:

1. One riskiest assumption, not all assumptions. Every founder identified the single biggest reason their business model could fail and designed the MVP to test exactly that. Not every assumption, one.

2. Real users, real behaviour, real money. Surveys measure opinions. MVPs measure behaviour. The strongest MVPs (Zappos, Groupon, Airbnb) involved real transactions, actual money changing hands for actual services delivered. Payment is the hardest test and the most reliable signal.

3. The MVP type matched the hypothesis, not the product vision. Dropbox’s vision was a full sync product; the MVP was a video. Amazon’s vision was a universal marketplace; the MVP was a bookstore. The MVP type was chosen to test the hypothesis efficiently, not to resemble the final product.

4. Constraints were features, not compromises. Uber’s invite-only constraint created scarcity. Spotify’s invite-only created word-of-mouth. Amazon’s bookstore-only focus meant the team could execute perfectly on one category before expanding. Constraints forced rigour.

5. The pivot came from behaviour, not surveys. Instagram’s pivot from Burbn came from watching which feature users were actually using, not from asking users what they wanted. Slack’s discovery came from its own team’s daily behaviour. The signal that drove the best product decisions was observed behaviour, not expressed preference.

How InApps Applies the MVP Playbook

InApps builds MVPs under the MVP Development service, starting with the hypothesis, not the feature list. Before any code is written, the InApps discovery process identifies:

1. The riskiest assumption, what single belief about the market, the user, or the technology, if false, would make the entire business unviable?
2. The MVP type that tests it most cheaply, is this a demand question (landing page), a workflow question (concierge), or a retention question (single-feature build)?
3. The minimum scope required, what is the smallest set of features that tests the hypothesis with real users and real behaviour?

Only after answering these three questions does InApps scope a build.

InApps MVP clients who followed this path:

• A B2B compliance SaaS founder came with a 40-feature spec. InApps identified the riskiest assumption (that compliance teams would pay $300/month for automated audit trail generation). The MVP: one feature (audit trail export), one integration (Jira), one pricing tier ($299/month). Shipped in 6 weeks. 23 paying customers in month one.
• A marketplace founder spent 2 weeks with InApps running a concierge MVP, manually matching supply and demand via email and spreadsheets, before any platform was built. The manual operation revealed a workflow problem that would have required 3 months of development to fix post-launch. It was fixed in a Google Sheet in 2 days.

Every founder thinks their product needs more features than it does. The job of the discovery process is to find the single feature that proves the business. Once you have that, everything else is a roadmap item, not a launch requirement.

Get a hypothesis-first MVP scoping session →, InApps identifies your riskiest assumption, recommends the MVP type that tests it, and scopes a build around validation rather than feature completeness.

Frequently Asked Questions

What is a minimum viable product example?

A minimum viable product example is a real case of a company testing a business hypothesis with the smallest possible build before committing to full product development. Famous examples include Dropbox (explainer video grew waitlist from 5,000 to 75,000 overnight), Zappos (founder manually bought and shipped shoes to test online purchase intent), Airbnb (founders rented air mattresses in their own apartment to test both sides of the marketplace), and Buffer (two-page website with a pricing gate proved willingness to pay before any product existed).

What makes an MVP different from a prototype?

A prototype demonstrates how a product will look or function, usually for internal testing or investor presentations. An MVP is a working version (or a deliberate simulation) released to real users to validate a specific business hypothesis with real behaviour and, ideally, real money. A Figma prototype shows what the product would be. A Wizard of Oz MVP delivers the service manually to real users who pay real money, without them knowing it is manual. The distinction is real users vs internal users, and real transactions vs demonstrations.

What is the most famous MVP example?

Dropbox is the most cited MVP example because it validated market demand with zero product code, a 3-minute explainer video grew the waitlist from 5,000 to 75,000 overnight. The Dropbox case illustrates the core MVP principle: test whether people want the thing before building the thing. The riskiest assumption was not “can we build file sync?” (Dropbox’s technical team knew they could), it was “do people care enough about this problem to take action?”

What type of MVP should I build?

The MVP type should match the hypothesis you need to test. Landing page or explainer video: for demand validation (“do people want this?”). Concierge or Wizard of Oz: for workflow and willingness-to-pay validation (“does this solve the problem and will people pay?”). Single-feature build: for retention validation (“do people return and continue paying after using it?”). Most B2B SaaS founders should run a concierge MVP before writing any code, manually delivering the service to 5 clients proves the workflow and payment model before committing to the development budget.

How much did famous MVPs cost?

Famous tech MVPs were built for far less than most founders expect. Dropbox’s video MVP cost approximately $2,000–$5,000 in production and editing. Buffer’s landing page cost under $500. Airbnb’s first website was built in a weekend for nearly $0. Zappos’s Wizard of Oz required only a basic website and founder time. The single-feature builds (Instagram, early Slack, early Uber) cost $10,000–$50,000, but only after the cheaper validation steps had already confirmed the hypothesis was worth testing. The pattern: spend $500–$5,000 to validate demand; spend $30,000–$60,000 only after the cheap validation succeeds.

What should I do after my MVP is validated?

After MVP validation, real users, real usage, real payment, real return behaviour, focus on one thing: understanding why it works before adding features. Interview every early user. Map exactly which part of the core loop produces retention. Identify the “aha moment”, the specific action after which a user is likely to become a long-term customer. Only then add features, prioritising the ones that help more users reach the aha moment faster. The post-MVP trap is adding features to impress users who have not yet found value in the core loop, which dilutes the product and slows learning.

Key Takeaways

• 12 MVPs, one common pattern: One riskiest assumption → cheapest MVP type to test it → real users, real behaviour, real money before full build.
• 5 MVP types: Landing page, explainer video, concierge, Wizard of Oz, single-feature build. Type matches hypothesis.
• 5 hypotheses all MVPs test: Demand → workflow fit → willingness to pay → retention → market size.
• Dropbox: Video → 5K to 75,000 waitlist overnight. No product code.
• Zappos: Founder bought shoes manually → proved people pay online before building any fulfilment infrastructure.
• Airbnb: Founders hosted themselves → discovered which side of the marketplace (supply/hosts) was the harder problem.
• Buffer: Pricing page before product → validated willingness to pay, not just demand.
• Slack: Internal tool for failed game → discovered product-market fit in own team’s daily behaviour.
• Instagram: Stripped failed product to one feature → 1 million users in 2 months.
• Uber: One city, black cars, invite-only → constrained MVP as rigour, not limitation.
• Groupon: WordPress blog + manual emailing → fastest-growing company in history (at the time).
• The strongest validation is payment. Surveys measure opinions. Real money measures behaviour.
• Constraints are features. Invite-only, single-city, one category, these created scarcity and forced focus that made MVPs sharper, not weaker.
• Startups with MVP + early data are 3× more likely to secure pre-seed funding (We Are Presta 2026). MVPs reduce development costs by up to 60%.