The best MVP examples are almost embarrassingly small. Dropbox started as a demo video. Airbnb started as three air mattresses. Zappos started with photos of shoes its founder didn't own. Each first version tested one risky idea, cheaply, before the team built anything bigger.
Most founders already know the theory: build small, learn fast, iterate. The hard part is deciding what "small" means for your idea and having the nerve to launch something that looks unfinished.
That's why real minimum viable product examples are more useful than definitions. They show how small the first version actually was and what each founder was trying to learn.
Below are 12 startup MVP examples, grouped by the type of MVP they used. For each one, you'll see what the first version was, what it proved, and the lesson you can borrow for your own launch.
Key Takeaways
Most famous MVPs tested demand before technology. Dropbox, Buffer, and Product Hunt proved people wanted the product before the full product existed.
Manual "concierge" MVPs (Zappos, DoorDash, Groupon) used human effort to simulate automation, then automated only what worked.
One feature, one city, or one audience was enough for Instagram, Uber, and Amazon to find traction.
Slack and Stripe started by solving their own team's problem or a narrow developer pain point, then widened their focus.
A good MVP answers one question. If yours tries to answer five, it isn't minimum yet.
What Makes a Good MVP Example?
A minimum viable product is the smallest thing you can ship that tests your riskiest assumption with real users. It's not a smaller version of your final product. It's an experiment.
Every one of the MVP examples below passes three tests:
It was shipped to real people, not just shown to friends.
It tested one clear assumption, such as "will people pay?" or "will people use this daily?"
The founders changed course based on what they learned.
Demand-Test MVP Examples (Before the Product Exists)
These MVP examples share one move: the founders checked whether anyone cared before building the hard parts.
1. Dropbox: A Demo Video Instead of a Product
The first version: A short screencast. In 2007, Drew Houston posted a demo to Hacker News showing files syncing across computers. A follow-up video, packed with in-jokes for the Digg community, reportedly took the beta waitlist from about 5,000 to 75,000 sign-ups overnight.
What it proved: File syncing was a problem people badly wanted solved. Building reliable sync across operating systems was expensive and slow, so the video tested demand before the engineering was finished.
Lesson for founders: If your product is hard to build but easy to show, a video can validate it. Aim it at a specific community and speak their language.
2. Buffer: Two Web Pages and a Pricing Button
The first version: Joel Gascoigne put up a landing page explaining a tool for scheduling tweets. Clicking "Plans and Pricing" led to a page with plans. Clicking a plan led to a note saying the product wasn't ready, plus an email signup.
What it proved: The extra pricing step showed that people were clicking on the paid plans, not just showing interest in the idea. According to Buffer's own account, the product launched on November 30, 2010, and got its first paying customer four days later.
Lesson for founders: Test willingness to pay, not just interest. An email signup is cheap; a click on a $10 plan means more.
3. Product Hunt: An Email List Built in 20 Minutes
The first version: In November 2013, Ryan Hoover used a link-sharing tool called Linkydink to create a daily email of new products. He has said it took about 20 minutes to set up. He invited friends and investors to submit products they liked.
What it proved: People in tech wanted a daily, curated feed of new products, and they were willing to contribute to it. The website came later, once the email had an engaged audience.
Lesson for founders: Use existing tools to test the habit before building the platform. If people won't open a daily email, they won't visit a daily website.
Concierge and Manual MVP Examples
These concierge MVP examples looked automated to customers, but humans did the work behind the scenes. Paul Graham's essay Do Things That Don't Scale makes the case for exactly this approach.
4. Zappos: Selling Shoes It Didn't Stock
The first version: In 1999, Nick Swinmurn photographed shoes at local stores in San Francisco and posted the photos online. When someone ordered a pair, he bought them at full retail price and shipped them.
What it proved: People would buy shoes online without trying them on. That was the big doubt in 1999, and he tested it without buying any inventory. Amazon acquired Zappos in 2009 for about $1.2 billion.
Lesson for founders: You can lose money on every early order if each one teaches you something. Margins can be fixed later; missing demand can't.
5. DoorDash: PDF Menus and a Phone Number
The first version: In January 2013, four Stanford students launched PaloAltoDelivery.com. It had PDF menus from a few local restaurants and a Google Voice number. The founders took orders by phone and delivered the food in their own cars.
What it proved: Suburban customers wanted delivery from restaurants that didn't offer it. Doing the deliveries themselves also taught the founders the logistics they'd later automate.
Lesson for founders: Do the job yourself before writing software for it. You'll learn which steps actually need code.
6. Groupon: A WordPress Blog and PDF Coupons
The first version: Groupon grew out of The Point, a group-action site. In late 2008, the team ran deals on a lightly customized WordPress blog and emailed PDF coupons to buyers by hand. The first deal was two pizzas for the price of one at a restaurant in their Chicago office building.
What it proved: Local daily deals with a group threshold could get people to buy. The rough back end didn't matter to customers who just wanted the deal.
Lesson for founders: Customers judge the offer, not your tech stack. A blog plus manual work can carry a business until volume demands more.
Ready to move past the spreadsheet stage? Once your manual MVP proves demand, StackMivo can turn it into a working Laravel app for founders with real authentication, a database, and a UI, so you can test with real users instead of a Google Form.
A quick founder scenario
Picture Aisha, a former operations manager who wants to build software for booking cleaners in small offices. Her first plan is a full marketplace with ratings, payments, and scheduling.
Instead, she starts the DoorDash way. She builds a one-page site with a booking form, and she schedules every cleaner herself by text message. After six weeks, she has 22 repeat office clients and a clear finding: clients don't care about choosing a cleaner. They care about having the same cleaner come back every week.
That one insight cuts her feature list in half. The marketplace she was about to build would have solved the wrong problem.
Single-Feature MVP Examples
The next three MVP examples launched with one feature, one market, or one product line, and nothing else.
7. Instagram: One Feature Cut From a Bigger App
The first version: Kevin Systrom and Mike Krieger first built Burbn, a check-in app with lots of features. Users mostly ignored everything except photo sharing. The founders cut the app down to photos, filters, comments, and likes, and launched it as Instagram on October 6, 2010, for iPhone only.
What it proved: Instagram reached about 25,000 users on day one and one million by mid-December 2010. The focused product beat the feature-packed one.
Lesson for founders: Look at what early users actually do, not what you hoped they'd do. Then cut everything else.
8. Uber: One City, One Car Type, One Tap
The first version: UberCab launched in San Francisco in 2010. Riders could request a black car through an iPhone app or by SMS. There was no UberX, no food delivery, and no other cities.
What it proved: People would pay more than a taxi fare for a car that showed up reliably at the tap of a button.
Lesson for founders: Pick the smallest market where your idea can work fully. One city done well teaches you more than five cities done badly.
9. Amazon: Books Before Everything
The first version: Amazon went live in July 1995 as an online bookstore. Books were a smart test: there were millions of titles, too many for any physical shop, and the products were easy to ship.
What it proved: People would trust a website with their credit card for a product they understood well. The "everything store" came after books worked.
Lesson for founders: Start with the product category where your advantage is clearest, even if your vision is much bigger.
Internal-Tool and Developer MVP Examples
Two of the most influential MVP examples started as something the founders built for themselves.
10. Slack: A Chat Tool Built for a Game Studio
The first version: Stewart Butterfield's company Tiny Speck was building an online game called Glitch. The team built an internal chat tool for themselves. When the game shut down, they realized the tool was the real product.
What it proved: Slack released a "preview" in August 2013, calling it that so people wouldn't assume a beta was buggy. It received about 8,000 invite requests on the first day and around 15,000 within two weeks.
Lesson for founders: If your team relies on a tool it built for itself, other teams might too. Your own daily use is a strong early signal.
11. Stripe: Seven Lines of Code
The first version: In 2010, Patrick and John Collison built /dev/payments, an API that let developers accept card payments with a few lines of code. Rather than wait for sign-ups, they offered to install it on a founder's laptop on the spot. Paul Graham called this the "Collison installation."
What it proved: Developers hated payment setup enough to switch to an unknown provider if it was dramatically simpler.
Lesson for founders: For developer products, cut the time to the first success. Then sit next to users while they get there.
Physical-World MVP Example: Airbnb
12. Airbnb: Three Air Mattresses in a Living Room
The first version: In October 2007, Brian Chesky and Joe Gebbia couldn't afford their San Francisco rent. A design conference was coming to town and hotels were full. They put up a simple website, AirBed & Breakfast, and rented air mattresses in their apartment for $80 a night. Three guests booked.
What it proved: Strangers would pay to stay in someone's home, and hosts would earn real money doing it. Nathan Blecharczyk joined to build a sturdier platform after that test.
Lesson for founders: Time your test to a moment of high demand. A sold-out conference made the idea easy to test.
Types of MVP: Which One Fits Your Idea?
The 12 startup MVP examples above fall into five types. Here's how to pick yours.
MVP type | Examples | Use it when | Main risk tested |
|---|---|---|---|
Demo video or landing page | Dropbox, Buffer | The product is expensive to build | Demand and willingness to pay |
Concierge or manual | Zappos, DoorDash, Groupon | The process can be done by hand | Will people buy and come back? |
Existing-tool MVP | Product Hunt, Groupon | A habit can be tested with email or a blog | Engagement |
Single-feature or single-market | Instagram, Uber, Amazon | Your idea works best when focused | Core value |
Internal tool or developer-first | Slack, Stripe | You are your own first customer | Usefulness in real work |
Ask these three questions first
What's the riskiest assumption? Demand, price, behavior, or technical feasibility?
What's the cheapest way to test it with real people? Often, it's not code.
What result would make you stop? Decide before you launch, so you can't explain away bad numbers.
Where software comes in
Videos, landing pages, and manual work answer "do people want this?" They don't answer "will people use this every week?" For that, you need a working product people can log into.
That's the gap many founders get stuck in. They've validated demand, but hiring engineers or an agency feels like too big a jump. A generated app can bridge it. With StackMivo, you describe your MVP in plain language and get a working Laravel app with logins, a database, and screens you can put in front of users.
If your MVP is an operations tool, our guide to building an inventory management system in Laravel shows what that looks like.
A second founder scenario
Consider Tom, a solo founder with a landing page for a client-portal tool for accountants. Like Buffer, his pricing page gets clicks: 140 visitors pick a paid plan in a month. He has demand, but no product.
Instead of spending three months learning to code, he generates a first version with file uploads, client logins, and a simple task list. Ten accountants from his waitlist start using it. Within three weeks, he learns that file requests matter far more than the task list, and he rebuilds the dashboard around them.
Have a validated idea and no engineering team? New StackMivo accounts get 20 free credits, no card required. Start building your MVP →
Common Mistakes These MVP Examples Avoided
Looking across all 12 MVP examples, a few patterns stand out in what the founders didn't do.
They didn't wait for polish. Groupon ran on WordPress. DoorDash used PDFs. Customers didn't mind.
They didn't build for every user. Instagram was iPhone only. Uber was one city. Amazon was books.
They didn't skip talking to users. The Collisons installed Stripe by hand. The DoorDash founders delivered the food themselves.
They didn't fall in love with version one. Burbn became Instagram. Glitch's chat tool became Slack.
One more scenario
Imagine Lena, a founder building a meal-planning app. She spends five months adding recipes, shopping lists, a calorie tracker, and social sharing before launch. On launch day, 300 people sign up. Two weeks later, 12 are still active, and she can't tell which feature kept them.
Had she launched with only shopping lists, the way Instagram launched with only photos, she'd have learned the same lesson in weeks, with a clear signal about what worked.
Frequently Asked Questions
What are some good MVP examples?
Dropbox is one of the most cited MVP examples. Its first version was a demo video that grew the beta waitlist from about 5,000 to 75,000 sign-ups, proving demand before the hard engineering was done.
What are the main types of MVP?
The common types are demo video or landing page MVPs, concierge or manual MVPs, MVPs built on existing tools, single-feature MVPs, and internal-tool MVPs. Each tests a different risk.
How long should it take to build an MVP?
It depends on the type. A landing page can take a day, and a concierge MVP can take a week. A working software MVP often takes weeks with a traditional team and less time with AI app builders that generate the first version for you.
Does an MVP have to be software?
No. Zappos, DoorDash, and Airbnb all started with mostly manual work and simple websites. Software comes in once you know which steps are worth automating.
What's the difference between an MVP and a prototype?
A prototype shows how a product might work, often to a small internal group. An MVP is shipped to real users to test a real assumption, such as whether they'll pay or come back.
Conclusion: Start Smaller Than Feels Comfortable
Every one of these MVP examples looked too small at the time. A video. Two web pages. A phone number and some PDFs. A chat tool for a game nobody remembers.
What they had in common was focus. Each first version tested one assumption with real people, as cheaply as possible.
If you're unsure people want it, test demand with a video or landing page.
If you're unsure how the service should work, run it by hand first.
If you've proven demand, ship a single-feature product people can actually use.
Use these MVP examples as a pattern library, not a script. Write down your riskiest assumption today and pick the cheapest test for it.
When you're ready to put working software in front of users, build your first version with StackMivo →. Start with 20 free credits and see the plans and pricing when you need more.