MVP examples: real products and what they launched with

Most MVP examples you will find online are retold so many times that the details have drifted. I have only included examples where the founder, the company or a contemporary source documented what happened, and each one is cited at the end. Where a popular version of a story goes further than the source, I have stuck to the source.

This is part of my guide to how to build an MVP.

What they launched with

Here is the short version. The detail for each follows.

Dropbox: a demo before a product

In April 2007 Drew Houston posted a link on Hacker News titled "My YC app: Dropbox - Throw away your USB drive". It was a screencast showing files syncing between computers. The post had no text beyond the title and the link.

The lesson is not that every MVP should be a video. File sync is hard to explain and easy to show, and the hard engineering had to work before anything could ship. A demo let people see the product working and react to it before the public launch. If your product is the same, hard to describe, obvious once seen, a demo can be a legitimate first test.

Buffer: testing the price before the product

Buffer is the cleanest example of testing demand in steps. Joel Gascoigne wrote it up himself in 2011.

1. 1

   A two-page site

   A page describing the product and a page to leave an email address. He tweeted the link and asked for opinions.

2. 2

   A pricing page in between

   One extra click before the email form, showing the plans. People kept signing up, and some clicked on paid plans.

3. 3

   Seven weeks of building

   Evenings and weekends, with a self-imposed deadline. He dropped a guided sign-up flow he considered vital to hit it.

4. 4

   Launch and first payment

   The product went live, rough around the edges, and the first paying customer came four days later.

What I like about Buffer is the pricing page. Most landing page tests only measure interest, and interest is cheap. A click on a paid plan is a much stronger signal, and it cost one extra page.

Zappos: doing it by hand

In a 2012 Fortune interview, Nick Swinmurn described the original 1999 model as going into stores, taking pictures and selling the shoes online. The shops held the stock, and the business only had to fulfil orders as they came in.

There was no warehouse, no supplier deals and no inventory risk. The one question was whether people would buy shoes online without trying them on, and the manual model answered it. The model changed later, once the answer was clear.

Airbnb: starting at home

Airbnb's own account is that it "was born in 2007 when two hosts welcomed three guests to their San Francisco home". The company was then called Airbed and Breakfast. Brian Chesky and Joe Gebbia were the hosts.

The first version did not need a marketplace of thousands of hosts, because the founders were the supply. Later, Paul Graham's essay on doing things that don't scale describes the founders going door to door in New York, recruiting hosts and helping existing ones improve their listings. That is the cold start problem solved by hand, and it is the same problem every marketplace has. I go into it further in the guide to marketplace MVPs.

Product Hunt: an email list first

Ryan Hoover started Product Hunt as a daily email using a link-sharing tool called Linky Dink, with a few dozen people from the startup world contributing products. He told The Next Web in 2014 that it took 20 minutes to set up. The website came afterwards, built with Nathan Bashaw over Thanksgiving.

Twenty minutes is an extreme example, but the principle travels. If the value is the curation, test the curation first, in whatever format costs least.

Stripe and Facebook: narrow on purpose

Two more from Paul Graham's essay, both about deliberately small starts.

Stripe. When someone agreed to try the beta, the founders did not send a link. They asked for the person's laptop and set them up on the spot. Graham calls it the Collison installation. It is onboarding done by hand, and it taught the founders exactly where new users got stuck.

Facebook. It launched for Harvard students only. A small, closed group was easier to fill than the whole internet, and Graham notes that its early users felt it belonged to them. It expanded beyond Harvard only after that.

What the examples have in common

Put side by side, the pattern is clear.

• Each one tested one question. Not "is this a good business", but something specific: will people pick a paid plan, will they buy shoes unseen, will strangers stay in a flat.
• Each used the smallest thing that could answer it. A video, two web pages, an email list, the founders' own home.
• The manual work was a feature, not a failure. Photographing shoes, installing software on people's laptops and recruiting hosts door to door all taught the founders things a built feature would have hidden.
• The first version was rough. Buffer's founder called his launch rough around the edges and still had a paying customer within a week.

The cut list for your own product follows the same logic. What to cut from your MVP goes through it area by area.

What the examples leave out

A word of caution. These are success stories told afterwards, and success stories make the path look straighter than it was. Many products started with a landing page, got sign-ups, and still failed. A test that says people are interested does not prove they will keep using the product.

They also come from a period when building software was slower and more expensive than it is now. Today an AI builder can produce a working prototype in a day, which changes the economics of the first test. It does not change the question. A fast build of the wrong product is still the wrong product, and the step from a prototype to something people can rely on still takes real work. If you are weighing that up, see whether to use AI tools or hire someone.

Applying it to your idea

Before you scope anything, write down the one question your MVP has to answer. Then ask what the smallest thing is that could answer it.

1. Is the question about demand? A landing page with a pricing page, or a demo, may be enough.
2. Is it about whether the product solves the problem? People need to use something real. Build the core job and do the rest by hand.
3. Is it about whether they will pay? Take real payments from day one, even if everything around them is manual.

Then scope your MVP in an afternoon and put the short list through the MVP cost calculator to see what it costs and how long it takes.