How Dropbox, DoorDash, Airbnb and Stripe designed their MVPs

You want to get your MVP in front of people quickly. You also want to give them a fair chance to use it. If they can’t understand what it does or how to use it, it’s hard to learn whether they’d find it useful.

Start with the first thing you want someone to accomplish. Work through what they need to see and do, then decide what can wait, what an existing tool can cover, and what your team can handle by hand.

Dropbox put its effort into one behavior people had to see working. DoorDash handled its first orders by hand, and Airbnb’s founders took listing photos themselves. Stripe started with a friend who could put up with the gaps, and Product Hunt began inside someone else’s tool. Their founders’ accounts show what each designed first and what it left for later.

Dropbox’s demo was a folder that kept itself up to date

In April 2007, Drew Houston posted an early Dropbox demo on Hacker News. In the discussion, he explained that files lived in a local folder and synced in the background. You could work offline and have changes sync when you reconnected.

The important interaction happened in a folder people already knew how to use. Saving a file was enough to keep every copy up to date.

Houston later explained in a Mixergy interview that the prototype could demonstrate the idea before the software was ready for unrestricted use. Desktop reliability was the harder problem. He also said the first Hacker News video was recorded in one take and wasn’t doctored. The software existed.

The screencast let viewers react to the interaction without installing Dropbox. The closed beta let a limited group install it and sync their own files, so Houston could get feedback from actual use.

That launch thread also produced BrandonM’s skeptical comment. He suggested you could get the same thing with an FTP account, curlftpfs, and SVN or CVS. Just a little systems administration between you and your files.

Houston replied that “the user experience (on windows at least) with online drives generally sucks.” A local folder meant nobody waited on a remote drive.

I don’t buy “you can already do that” as a reason to dismiss a product. With Dropbox, a familiar folder did work that otherwise meant configuring and combining several tools. You could use Dropbox without having to learn any of those tools.

DoorDash’s MVP was a phone number, a car, and a few PDFs

In his 2014 startup lecture, DoorDash cofounder Stanley Tang described putting PDF restaurant menus and a phone number on a landing page. The team wanted to find out whether people would call to order delivery.

They did. The founders picked up the food and delivered it themselves. Existing tools covered other needs, including Square for charging customers and Google Docs for tracking orders. Driving, dispatching, and answering support questions taught them about the work they would later automate.

DoorDash could take real orders before it had a custom dispatch system. The founders’ own driving and dispatching stood in for it until they knew people would order.

If your team can take a request and do the work by hand, use existing tools to manage it. A custom dashboard can wait. The customer still needs to know what they’re being promised, and someone on the team has to own delivering it.

Tang also recalled a limit to this approach in a later Stanford talk. In September 2013, months after the first delivery, a football-night surge overwhelmed the team. They had too few drivers and hadn’t built a way to stop incoming website orders. Deliveries ran late.

A way to pause orders belongs in the MVP. Agree on how much work the team can take and how it will stop new requests before the team gets overwhelmed. Hungry customers still expect dinner (even if the founders are doing the driving).

Airbnb’s founders took the listing photos themselves

Airbnb’s first test was small enough for the founders to host the guests themselves. In his founders’ letter, Brian Chesky recalls how he and Joe Gebbia hosted three people on airbeds in their apartment during a 2007 design conference.

Helping other people become hosts brought different problems. In his 2014 YC lecture, Chesky described staying with a New York host whose home looked much better than its photos. She couldn’t work out how to transfer photos from her camera to her computer.

Chesky photographed the home himself. He and Gebbia then handled other photography requests, renting a camera and coordinating the work with spreadsheets. Management tools came later, after they had experience running the service.

Helping hosts supply useful photos became part of Airbnb’s service. That content work needed attention early, even while the founders were taking the photos themselves.

I’d fix weak listing content before paying for a redesign. Check the content the first customer will see. Does it give them enough information to choose?

Stripe chose a first user who could work with an unfinished product

Stripe began with an API that could charge cards. In a 2012 interview with Mixergy, cofounder Patrick Collison described the team adding refunds and transaction-viewing features as requests came in. He was unsure whether even a minimal interface for viewing charges existed on day one.

The first user was Ross Boucher, a friend who needed to accept payments and whose technical and design judgment they respected. The founders were upfront about the product’s gaps and would build in response to his feedback. Collison said that level of incompleteness would not have been acceptable for an ordinary paying user.

In another early interview, he described manually arranging the underlying account setup through a contact at a payment processor. At that point, they had two users, both friends.

By Collison’s later account at Startup School, the first production use was in January 2010. Public launch followed in September 2011. Before then, Stripe needed security, payment partnerships, and dependable payouts so businesses could sign up and take payments on their own.

Ross could tell the founders directly what was missing, and they could build it for him. A friend in the room made up for missing setup screens and documentation. A customer signing up alone would have to rely much more on the product’s setup and instructions.

For a developer product, the API and the instructions are part of the interface. Don’t assume a stranger signing up will give you the patience Ross did. Agree on how much personal support the first users will have, then design for what they’ll need to do alone.

Zapier showed how a tweet could turn into a contact

Zapier’s founders were working against a Startup Weekend deadline in 2011. They also had a difficult idea to explain to people who weren’t developers. Connecting two services through their APIs needed to make sense on screen.

In Wade Foster’s account of that Saturday, Mike Knoop sketched wireframes and gathered feedback from other attendees before building the interface. The frontend and backend were still disconnected that night, but they were already spending time finding out whether people understood the flow.

For Sunday’s demo, the team dropped the dashboard and concentrated on the interaction the audience would see. The demonstration connected Twitter mentions to contacts in Highrise, a customer-management tool.

Good cut. The audience needed to see what connecting two services would do for them before they needed an overview of their connections.

A dashboard appeared as the product developed. Foster’s 2012 year review describes revising the UI after beta customers asked for something better.

Product Hunt started as a Linkydink group

Product Hunt began in November 2013 with a Linkydink group. In his launch announcement, Ryan Hoover described contributors submitting product links through the group or an email address. Subscribers received a daily digest with credit to each contributor.

A borrowed tool was enough to test the daily habit. Hoover didn’t need a custom interface to find out whether people kept contributing and reading.

Linkydink handled link collection and the daily email, but Hoover wanted a place to discuss those discoveries. Building the custom site meant designing product-submission fields, voting controls, and a way to read and write comments. Cofounder Nathan Bashaw’s account describes making names and taglines easy to scan and opening discussions in a side pane.

Hoover and Bashaw kept Linkydink’s grouping of products by day in the new site. The email experiment had already given them a structure for presenting each day’s discoveries.

Put the effort where the first customer needs it

I’d use these stories to decide where the design budget goes.

Familiar controls and a small set of consistent styles can be enough to start. Spend more time on anything that could leave the customer unsure what to do, what they’re getting, or whether their action worked.

I work on SaaS UI/UX and React frontend development. Use the inquiry form below to share your idea, the problem you’re trying to solve, and any budget or deadline. I can help you choose what to design first and whether to begin with a prototype, a working flow, or a technical investigation.