10 Best MVP Examples to Study Before You Start Building

You have an idea. Before you've said a word to a real customer, you're three tabs deep comparing databases, picking a font, and arguing with yourself about whether this needs a mobile app on day one.

That's where most good ideas die: months of building poured into something no one wanted.

I went back through founder interviews, original news coverage, and company archives to find out what the first working versions of Airbnb, Dropbox, Amazon, and seven other companies looked like, long before anyone called them successful.

Then I opened Emergent and tried the same approach myself on a brand-new app idea, to see how fast that kind of test can happen today.

Across all ten companies, none of the first versions looked like the businesses they became. A few were held together by one person doing everything by hand behind the scenes. What they all had in common was a single, specific bet and a fast, cheap way to find out if it was right.

You'll see exactly what each of these MVPs looked like at the start, what happened the moment real people saw them, and the one lesson from each you can put to use today.

What Is an MVP? A Primer Before These MVP Examples

A minimum viable product (MVP) is the smallest version of an idea that lets you test one specific bet with real people: Will people want this?

Every example below skips the parts that don't decide whether the bet holds up. The polish, the scale, and the extra features can all wait. Only the part that proves or disproves the idea comes first.

If you want the full step-by-step process once your own bet is validated, building an MVP starts with picking that one bet first.

What an MVP Is Not

An MVP gets confused with three other things constantly, and the mix-up costs founders real time.

A proof of concept tests whether something can technically be built, and it's often discarded once it answers that question. An MVP uses the smallest credible version people can respond to, which may be a working product, a manual service, or a demonstration.

"Minimum" doesn't mean sloppy. Zappos's photographed shoes and Groupon's WordPress blog were both bare-bones, but every part of them worked well enough to complete a real transaction. Calling a broken checkout or a listing that doesn't load "leaner" is generous. It's a bad MVP.

A finished product with fewer features is a separate idea. An MVP is the one narrow slice that proves or disproves the idea's central bet, and everything else you're picturing when you imagine the "real" version can wait until that bet is proven.

The Four MVP Patterns These Stories Follow

The ten stories below reveal four repeatable patterns, though a few fall outside them. Identifying the closest pattern can help you decide what your first version needs to include.

• Wizard of Oz: The product looks automated from the outside, but a human was doing the work behind the curtain. Zappos is the clearest example: shoppers saw a working store, but every "fulfillment" was Nick Swinmurn buying the shoes himself after the sale.
• Concierge: A person delivers the whole experience directly, with no automated interface pretending otherwise. Airbnb worked this way through the founders hosting guests themselves.
• Piecemeal: You test the idea using tools and platforms that already exist, without building any of your own. Groupon worked this way through Mason posting each day's deal on WordPress, and AngelList's original version fits too: Naval Ravikant and Babak Nivi tested demand for a curated deal list using nothing but ordinary email, before building any platform at all.
• Narrow-Scope: You strip the product down to the one category, audience, or workflow that proves the mechanism, cutting everything else. Amazon (one category, books), Uber (one basic request-and-respond loop), and Facebook (one campus, one directory feature) all fit this pattern: everything that wasn't the core mechanism got cut.

A few stories don't fit any of the four patterns above, and that's the point of including them. Dropbox tested demand before any product existed at all, using only a video describing what the product would do.

Duolingo and Spotify are the opposite case. Some bets can't be faked by hand, on a landing page, or with a human standing in for the software. When the thing you're testing is a behavior or a technical experience, you may need working software before you can test anything at all.

Why an MVP Is Worth Doing (and What Skipping One Costs)

The point of building an MVP before the full product runs deeper than speed for its own sake. If you test for it before you spend the money, most of what kills a startup is knowable in advance.

CB Insights analyzed 431 VC-backed startups that shut down since 2023 and identified failure reasons for 385 of them. Running out of capital was the top cause cited, at 70%.

But the firm treats that as the final symptom, not the root problem: poor product-market fit shows up in 43% of the post-mortems, the biggest reason the capital ran out in the first place. That's the exact failure every story on this list was built to avoid.

Amazon didn't need a warehouse to find out whether strangers would trust a website with a credit card. Groupon proved a daily deal, redeemed in person, was worth repeating without spending anything on real software.

Skipping the MVP step risks more than a slower build of the wrong thing. It risks building a lot more of the wrong thing before anyone finds out it's wrong.

The 10 MVP Examples, One Company at a Time

These are the 10 companies with a real, checkable account behind their first version. Each one narrowed its first version around the questions that had to be answered first.

1. Airbnb: Three Guests on Air Mattresses During a Sold-Out Conference

What it was: In October 2007, roommates Brian Chesky and Joe Gebbia couldn't cover their San Francisco rent. A design conference had sold out every hotel in the city that week.

So they pulled air mattresses out of a closet, threw together a basic website, and offered a spot on their apartment floor for $80 a night.

At that point, the whole operation was a listing and a price. A company, reviews, and a way to collect payment weren't part of the picture yet.

In Chesky and Gebbia's own retelling of that weekend, Gebbia describes the moment the idea got its name: "We pulled out a couple of air beds from our closet. Laid them out and we said, 'Oh, that is going to be the air bed and breakfast.'"

If nobody had responded, or if guests had balked at paying to sleep on a stranger's floor, the idea would have gone back in the closet with the air mattresses.

What happened: That weekend, two hosts welcomed three guests to their San Francisco home. Three strangers were willing to pay to sleep on an air mattress during a sold-out week, and that was the test.

It's a tiny number by any modern standard. But it answered the only question that decided anything at the time: Would a stranger pay for this? The answer was yes, and that was proof enough to keep building.

No reviews existed to build trust, and no payment platform processed the $80. The founders collected cash in person, so the only thing being tested was whether a stranger would say yes at all.

The lesson for your own MVP: Test the match by hand before you build any matching software. When two groups of people need connecting, one listing and one taker is proof enough to start. That's true whether you're matching hosts and guests, buyers and sellers, or riders and drivers.

A two-sided marketplace doesn't need a real platform for its first proof. Before you build the software that automates the matching, it helps to know how a two-sided marketplace works.

2. Dropbox: A Video of a Product That Didn't Exist Yet

What it was: Drew Houston didn't have months to spend building file-sync software before finding out whether anyone wanted it. In 2007, while applying to Y Combinator, he recorded a short screen-capture video showing how the finished product would work.

He posted it where the most technical, most skeptical audience he could find would see it first.

There was no working software behind the video. Houston narrated a demo of a product that didn't exist yet and packed it with inside references only a developer audience would catch. He aimed it at people who would immediately understand the technical problem before trusting a stranger's claim that he'd solved it.

Houston's own account of that post describes the gamble plainly: "My (perhaps questionable) strategy for getting into Y Combinator: 1) Post a Dropbox demo on Hacker News 2) Pray Paul and Jessica see it. It actually worked. The video hit #1 on HN for two days (!), and a couple months later, we were part of the Summer 2007 batch."

What happened: The video hit #1 on Hacker News for two days, and Houston's application landed him in Y Combinator's Summer 2007 class within a couple of months. Houston later posted a second demo video to promote Dropbox's private beta, and that video is the one credited with pushing the beta waitlist up sharply overnight.

Weak interest would have been Houston's cue to walk away before writing a line of the syncing engine.

A short video costs almost nothing next to months of engineering work. That's the trade Houston made: prove people wanted the outcome before spending months building the technical work underneath it.

It's tempting to spend six months polishing an unfinished, technically hard product when a rough mockup would answer the same question faster. That instinct is exactly backward, and Houston's own HN post is the proof.

The lesson for your own MVP: If a video can show the finished experience clearly, working code doesn't need to exist yet to find out whether people want it. Build the code once you know they do.

That's the move if you're testing your own SaaS business idea. Show people the outcome first, then build the engine behind it once you know they want it.

3. Zappos: Photographing Shoes He Didn't Own

What it was: In 1999, Nick Swinmurn set out to test one specific bet: People would buy shoes online without ever trying them on. He didn't build a warehouse or negotiate supplier deals to find out.

Instead, he walked into local shoe stores, photographed their inventory, and posted those photos online as if they were his own listings. No real stock sat behind any of it.

A Fast Company account of the strategy Hsieh and Swinmurn built Zappos around traces how scrappy that first version stayed before any real infrastructure existed.

Swinmurn himself later laid out the evidence that made him confident enough to start, in an interview with Footwear News: "It was the fact that 5 percent of a $40 billion shoe business was already being done through mail order. That was my big statistic. People were already buying shoes without trying them on."

What happened: When an order came in, Swinmurn went back to the store, bought the shoes at full price, and shipped them himself. Every sale meant a trip to the store and a loss on the markup, but it answered the question.

People placed orders for shoes they'd never touched or tried on. That was the entire signal: Enough people were willing to buy sight unseen that the idea was worth building inventory and logistics around. Each order still required Swinmurn to drive to a store before the company had a warehouse, supplier deal, or automated fulfillment.

Zappos was later acquired by Amazon, and Amazon's own July 2009 announcement valued the all-stock deal at roughly $807 million at the time it was signed.

This test required Swinmurn to lose money on the early orders, a detail often skipped in retellings. He treated those early sales as a controlled loss to test demand before judging whether the business could become profitable.

The lesson for your own MVP: When people need to pay for something, fulfill those first orders by hand, even at a loss. Running fulfillment by hand is a legitimate way to test a transaction before you build anything to automate it. Once you know people will pay, build the systems that make it profitable.

4. Groupon: A WordPress Blog Posting One Deal a Day

Groupon Homepage in 2012

What it was: Before Groupon existed, Andrew Mason had already built a different idea called The Point, funded with $1 million in seed money from investor Eric Lefkofsky. It never found real traction as a platform for organizing group action.

By 2008, Mason and his team had dismantled most of its features and pivoted what remained into something much smaller.

The new version was a plain WordPress blog that posted one local deal a day, with no real software behind the redemption process. A shopping cart and a merchant dashboard didn't exist. Customers had to show up in person to redeem the deal.

Mason himself has described how crude that first version was: "All we did was we took a WordPress Blog and we skimmed it to say Groupon, and then every day we would do a new post with the points embedded. It was totally ghetto."

What happened: The first deal offered two-for-one pizza at a restaurant in the same building as their office. It got 20 redemptions, a small number that still proved the core mechanism worked.

People found a daily deal on a blog, then showed up and redeemed it in person. That single test worked without custom redemption software and showed the team they could repeat it in more cities with more businesses.

Mason ran this test without recruiting a new audience. He reused The Point's existing email list for a much smaller, sharper idea and didn't need to start from zero. The pivot didn't require a single new user, only a narrower promise to the users he already had.

Twenty redemptions wouldn't impress an investor on its own, but it told Mason that a daily deal, redeemed locally and sold through nothing more than a blog post, could work before he spent a dollar building software around it.

The lesson for your own MVP: Connect local businesses with customers and prove people will show up first, with no platform required. One deal and one place willing to honor it is enough. The "product" itself amounts to a publishing habit. The commission Groupon took on each redemption is one example of how apps make money today.

5. AngelList: A Curated Email List for Busy Investors

AngelList Homepage in 2010

What it was: Busy investors don't read unsolicited pitches, so Naval Ravikant and Babak Nivi built around that habit. In February 2010, they launched AngelList as a curated email list grown out of Ravikant's earlier Venture Hacks blog. At launch, it was already a directory of over 80 established angel investors. A website to log into and a platform to browse hadn't been built yet.

As Ravikant has put it himself: "Emails are a great way to prototype a business."

The list was tiny by newsletter standards, but its tight curation meant the few people reading it acted on what they saw.

What happened: The email list gained enough traction that its volume became overwhelming. That was the signal Ravikant and Nivi used before building the website. By Ravikant's own account, within about 18 months the list-turned-platform had facilitated 8,000 introductions and 400 investments.

A small email list carried the early test without a dashboard, investor accounts, or a way to browse startups. Those messages had to do all the convincing.

If the list had stayed quiet, with low volume and little response, there would have been no reason to build a marketplace around the idea in the first place.

The lesson for your own MVP: Send the right information to a small group, and you may already have your whole test. A login page for them to use isn't needed yet. The MVP can be only a distribution list. The curation counted for more than any platform would have.

The same logic scales down to any idea that lives or dies on getting information to exactly the people who'll act on it. A handful of carefully chosen readers can prove more than a stadium of indifferent ones.

6. Amazon: A Bookstore Run Out of a Garage

What it was: Bezos was testing something narrower than whether people would shop online in general: Would a stranger hand over a credit card number for something they'd never held? He incorporated the company in 1994 and launched the site on July 16, 1995, selling exactly one category: Books.

He ran the operation out of a garage, packing and shipping every order himself in the earliest days. There was no marketplace of third-party sellers or other product categories, only books ordered sight unseen over the internet.

One category kept the listings, shipping, and customer questions consistent. Every early problem belonged to books, while a dozen categories would have created a dozen sets of problems on day one.

What happened: Orders came in. A historical account of Amazon's early years puts the total at $12,000 worth of books sold in the first week. Three months later, Amazon's own press release described a catalog that had already grown to "more than one million different titles, 40 times more than typical mall bookstores". That catalog growth showed the early trust experiment expanding from a small bet on books to a much broader selection.

No orders, or carts abandoned at payment, would have sunk the trust test before Amazon ever reached a second category. Books alone were enough to test whether a stranger would trust a website enough to complete a purchase.

The lesson for your own MVP: Confirm people will complete the transaction before you widen what you're selling. Pick one narrow category, then judge the underlying mechanism by that alone.

If your idea eventually needs to cover a huge range of products or services, resist the urge to launch wide. Test the mechanism with one category first, then let the proof tell you when to expand.

7. Facebook: A Campus Directory Built for One School

What it was: A real name and Harvard email address were the entire bar for joining Thefacebook. Mark Zuckerberg launched "Thefacebook" on February 4, 2004 and restricted it to Harvard students. The product was a directory of real, identified classmates.

A closed directory for one specific campus was the whole product. It came without a news feed or photo tagging, and there was no expansion plan announced on day one.

Five days after launch, the Crimson quoted Zuckerberg directly on why he'd built it himself: "Everyone's been talking a lot about a universal face book within Harvard. I think it's kind of silly that it would take the University a couple of years to get around to it. I can do it better than they can, and I can do it in a week."

What happened: That same contemporaneous Crimson report put registrations at over 650 students within the first several days, and a later Crimson retrospective puts the count at 4,300 within two weeks. That kind of voluntary, fast adoption at one school was the signal Zuckerberg needed before expanding anywhere else.

The Harvard email requirement filtered out anyone who wasn't a student, so every signup represented a real Harvard student choosing to join without payment.

A few hundred students signing up and stopping there would have made a much weaker bet. A closed, identity-verified directory needed strong, voluntary adoption to prove itself, and there was no marketing budget behind it to force the numbers up.

The lesson for your own MVP: Can one clear, small audience validate your idea before you reach anyone else? Keep the audience to one sharply defined group first. That narrow group does the validating on its own. A strong result in one school, one city, or one company tells you far more than a thin result spread across a huge audience.

8. Uber: Three Cars Testing a Basic Request-and-Respond Loop

What it was: Garrett Camp and Travis Kalanick built Uber's first version to solve their own problem: struggling to find a cab in San Francisco. Before the product launched there, they tested the idea somewhere else first.

In Uber's own account of its founding, the company puts it plainly: "By January 2010 we did our first test run in New York. We had 3 cars cruising the SOHO/Chelsea/Union Square areas."

A rider sent a request by text or a basic app, and a driver responded. The first version left out ratings, surge pricing, and a multi-city rollout. That single exchange was the whole thing, carried by a handful of cars in a few neighborhoods.

The first test focused on whether a driver would show up when a rider asked, while ratings and surge pricing could wait.

What happened: A few people used the system during the New York test. Uber's own newsroom dates the San Francisco launch precisely: "San Francisco launch day was May 31st, 2010." Only after New York had already proven the idea did Uber commit to opening for real in the city the founders had built it for.

If riders' requests had gone unanswered during those early days, the idea could have stalled before reaching San Francisco.

The lesson for your own MVP: A service that depends on real-world timing can start with a single-city, single-feature test of its core exchange. A driver has to show up. A rider has to get picked up.

Scope your own test down to one place and one flow before you try to make it work everywhere at once. Prove the mechanism first, then widen the map.

9. Duolingo: A Free Product Built on Crowdsourced Work

What it was: The bet behind Duolingo went deeper than language learning: whether people would do it for free, day after day, as long as it felt like progress. Von Ahn described the sense of progress the real-world exercises were designed to create: "When you're doing the real-world stuff, such as reading a news report in German or French, you really feel like you're accomplishing something."

Luis von Ahn and Severin Hacker began sketching out the idea in 2011, while von Ahn was still teaching at Carnegie Mellon. The public product didn't open until the following year, launching in 2012 with courses that taught English speakers Spanish and German.

There was no premium tier or certification business yet. The original monetization plan relied on learners practicing with real sentences pulled from the web, with the aim of selling those crowdsourced translations to businesses.

The free lessons tested whether learners would return, while the translation plan tested whether their work could support a business.

What happened: By 2019, seven years after the first public launch, Duolingo had grown to nearly 30 million active monthly users, showing that it had reached a large monthly audience.

A single day of use proves nothing about a habit. Von Ahn and Hacker needed to see the same person open the app again without being asked, more than once, before the core bet held up.

One-time users who tried it and vanished would have killed the entire premise (that gamified repetition could replace a classroom), no matter how good the exercises were.

The lesson for your own MVP: If your idea depends on a habit forming, measure return visits. Some ideas test a behavior: Will people stick with this? A single glowing reaction proves nothing if nobody comes back the next day.

10. Spotify: A Working Product Before a Real Launch

What it was: Spotify was founded in April 2006, but it didn't reach outside users for more than two years. Daniel Ek and Martin Lorentzon spent that stretch building a working desktop streaming product and negotiating licensing deals with record labels.

The bet was specific: Instant, near-zero-latency streaming was what would get people to abandon piracy, more than ownership ever could. Ek has put his own goal plainly: "I decided I wanted to create a product that was better than piracy." Testing that claim required real playback that felt instant the moment someone hit play.

Spotify's own visual history marks the moment the two-year build finally reached real users: a launch in Finland, France, Norway, Spain, Sweden, and the UK in October 2008.

What happened: The October 2008 launch put Spotify's near-zero-latency streaming claim in front of real users outside the company for the first time.

Streaming that lagged the way pirated downloads or early competitors did would have undermined the premise that legal streaming could beat piracy on convenience. Ek and Lorentzon spent more than two years building the product and securing licensing deals before the October 2008 launch.

Here, speed to test was secondary to building a usable experience.

The lesson for your own MVP: Some bets require working software because speed, latency, and reliability only show up once the software is running.

If your idea lives or dies on how something feels in the moment, you may need working software to test it. That can mean a longer road to your first real users than Dropbox or Airbnb had.

Which Lesson Applies to Your Own MVP?

Not every one of these stories fits the same kind of idea. Match your own bet to the pattern below before you decide what your first version needs to look like.

• If you can test demand without working software: Dropbox used a video to test interest in frictionless file sync. AngelList used a curated email list before building a platform.
• If you can run the process by hand before automating it: Zappos and Airbnb handled early orders or bookings themselves. Groupon coordinated a daily deal through a blog and local merchants without a custom platform.
• If a single, narrow slice proves the whole mechanism: Amazon started with only books. Facebook started with only Harvard students. Uber started in only one city.
• If the thing you're testing can't be faked and needs real software: Duolingo and Spotify both had to build actual working software. The behavior or experience they were testing couldn't be faked with a landing page.

Best Practices Across These MVP Stories

A few patterns repeat across all 10 of these stories, no matter how different the products ended up being.

• Prove demand first: Airbnb, Dropbox, and AngelList skipped a full platform and tested demand through a listing, video, or email.
• Match the finish to the test: Groupon and Zappos could test demand with rough first versions, while Spotify and Duolingo needed working software that delivered the experience being tested.
• Set one sharp bet: Facebook bet on a single campus. Amazon bet on a single category. Each founder picked one claim to test, with a clear signal for what would prove it wrong.
• Move fast on a positive signal: Once the bet paid off, the teams expanded the test or built more of the product.
• Judge the mechanism itself: The exact test each company ran is worth copying. The eventual size of the business isn't part of the lesson.

How Emergent Helps You Test Your Own MVP Idea

Several companies on this list invented a workaround to test demand. Chesky and Gebbia used air mattresses, Houston recorded a video, and Swinmurn photographed inventory he hadn't bought.

Some of those early demand tests are faster to build today. To see exactly how fast, I opened Emergent and described a landing-page test for a fictional trail-tracking app called Trailmark. The goal was simple: See how quickly the scrappiest version of an idea like Dropbox's comes together now.

The prompt:

"Build a simple one-page landing site for a product called Trailmark: a headline that says it helps hikers log and share trail conditions in real time, three bullet points on what it does, and a single email field with a 'Notify Me' button that saves the email to a list. No other pages, no login."

Emergent turned that into a working page in six minutes, using nine credits, with 0 failures. I never picked a template, set up hosting, or wrote a line of code. I described the page, and Emergent built it.

Because nobody outside the test saw Trailmark, the six-minute result measured page-building speed. Showing it to real users would complete the Dropbox-style demand test.

Emergent can build the test itself, whether it's a landing page, waitlist, or single feature from these vibe coding examples. It can also build the database, sign-in, and underlying logic behind a full working product, the kind of build that used to take engineering teams weeks or months, now handled through prompts.

Signups and usage still determine whether people want the idea, while Emergent reduces how much building stands between you and finding out.

The smallest valid test depends on the bet: a page or video can test demand, while a technical experience may require working software.

Here's how Emergent helps with testing your own MVP idea:

• A test page in minutes: The Trailmark landing page went from a single written description to a working page in six minutes. That's fast enough to prepare a demand test the same day you have the idea, before showing the page to real users.
• Help when you're stuck starting: If you're not sure how to describe your test, Emmy, Emergent's in-product assistant, can turn a rough idea into a build-ready prompt, and using it costs no credits.
• A cheap enough attempt to throw away: The build used nine credits, inside what Emergent's free plan gives you in a month. Testing an idea shouldn't cost more than the idea is worth proving.
• Faster iteration: Most founders in this list eventually had to turn a hand-built test into real software. With Emergent, changing the bet (a different headline, a different single feature) means describing it again, not rebuilding from scratch.
• Setup handled for you: Hosting, templates, and environment setup are handled automatically. Airbnb and Dropbox's founders skipped building real infrastructure at all by faking their MVPs by hand; Emergent skips the manual setup work by building the real, working version directly.

Try Emergent to build and test your own MVP idea the way Trailmark was built here, before you decide whether it's worth building any further.