--- title: "How Dropbox, DoorDash, Airbnb and Stripe designed their MVPs" url: "https://sarthakmishra.com/blog/how-startups-designed-their-mvps" description: "Early UI and founder stories from Dropbox, DoorDash, Airbnb, Stripe, Zapier, and Product Hunt. What to design first, reuse, and leave for later." image: "https://sarthakmishra.com/og-images/blog/how-startups-designed-their-mvps.webp" --- [View HTML](https://sarthakmishra.com/blog/how-startups-designed-their-mvps) · [Site index](https://sarthakmishra.com/llms.txt) November 3, 2026 # How Dropbox, DoorDash, Airbnb and Stripe designed their MVPs Early UI and founder stories from Dropbox, DoorDash, Airbnb, Stripe, Zapier, and Product Hunt. What to design first, reuse, and leave for later. [Let's work together](https://sarthakmishra.com/blog/how-startups-designed-their-mvps#inquiry) ![Hands guide three sequential interface cards from image selection to a completed checkmark.](https://sarthakmishra.com/assets/how-startups-designed-their-mvps-hero-B8idXjsm.jpeg) 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](https://news.ycombinator.com/item?id=8863). 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](https://mixergy.com/interviews/drew-houston-dropbox-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. ![Dropbox's early web interface in Firefox on Windows XP, showing recent file changes and links to files, workspaces, and account settings.](https://sarthakmishra.com/assets/dropbox-demo-2007-CpJ97Lzy.jpeg) A frame from Drew Houston’s [original April 2007 Dropbox screencast.](https://s3.amazonaws.com/scast/video.flv) That launch thread also produced BrandonM’s [skeptical comment](https://news.ycombinator.com/item?id=9224). 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. ![BrandonM's April 5, 2007 Hacker News comment questioning Dropbox's advantages over FTP and version-control tools, offline access, and revenue prospects.](https://sarthakmishra.com/assets/dropbox-hacker-news-2007-CbjtDypX.jpeg) BrandonM’s April 5, 2007 comment in the [original Hacker News thread](https://news.ycombinator.com/item?id=8863). Houston [replied](https://news.ycombinator.com/item?id=9272) 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](https://www.ycombinator.com/library/JL-how-to-start-a-startup-getting-started-getting-press-and-doing-things-that-don-t-scale), 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. ![DoorDash's 2013 website offering Palo Alto restaurant delivery for six dollars, with restaurant selection and delivery hours.](https://sarthakmishra.com/assets/doordash-launch-2013-kqHweE4W.jpeg) DoorDash’s June 2013 launch website, after the first phone-order experiment. Screenshot shared in [cofounder Tony Xu’s anniversary note](https://about.doordash.com/en-us/news/doordash-celebrates-its-10th-dashiversary). Tang also recalled a limit to this approach in a [later Stanford talk](https://stvp.stanford.edu/av/stanley-tang-doordash-scaling-unscalable-entire-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). ![Tony Xu walking along a Palo Alto sidewalk carrying a red insulated delivery bag and a paper food bag.](https://sarthakmishra.com/assets/tony-xu-delivering-2014-DbqXaaRp.jpeg) DoorDash cofounder Tony Xu on a delivery in 2014. Photograph by Vicki Thompson / Silicon Valley Business Journal, from [its early DoorDash coverage](https://www.bizjournals.com/sanjose/news/2014/03/17/doordash-enters-food-delivery-fray-with-much.html). ## 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](https://news.airbnb.com/what-makes-airbnb-airbnb), Brian Chesky recalls how he and Joe Gebbia hosted three people on airbeds in their apartment during a 2007 design conference. ![AirBed and Breakfast's 2008 homepage, showing an event search form, separate sections for hosts and guests, and a featured Web 2.0 Expo event.](https://sarthakmishra.com/assets/airbnb-homepage-2008-KqMqORft.jpeg) The AirBed & Breakfast website in 2008, between the first apartment test and the photography work below. Screenshot from [Airbnb’s official timeline](https://news.airbnb.com/about-us). Helping other people become hosts brought different problems. In his [2014 YC lecture](https://www.ycombinator.com/library/JN-how-to-start-a-startup-building-company-culture-part-i), 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](https://mixergy.com/interviews/patrick-collison-stripe-interview/), 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](https://www.startupgrind.com/blog/from-the-vault-patrick-collison-stripe-full-startup-grind-interview-2012/), 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](https://www.ycrootaccess.com/p/patrick-collison-what-if-you-succeed), 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. ![Stripe's circa-2011 homepage showing a short curl request to create a card charge beside the heading An API that gets out of your way.](https://sarthakmishra.com/assets/stripe-homepage-circa-2011-DSiQPoBZ.jpeg) Stripe’s homepage API example, circa 2011. Screenshot reproduced in [Stripe’s API retrospective](https://stripe.dev/blog/payment-api-design), courtesy of the Internet Archive Wayback Machine. 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](https://zapier.com/blog/startup-weekend-part-iii-pushing-through-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](https://zapier.com/blog/startup-weekend-part-iv-sunday-demo-day/), **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](https://zapier.com/blog/zapier-100-connected-services-year-review/) describes revising the UI after beta customers asked for something better. ![Zapier's April 2012 dashboard with active, inactive, and unfinished Zaps beside a stream of recent actions.](https://sarthakmishra.com/assets/zapier-dashboard-2012-lYOgen7f.jpeg) Zapier’s Version 1.0 dashboard, April 2012, after the Startup Weekend prototype. Native-resolution frame from [Zapier’s original frontend demo](https://www.youtube.com/watch?v=gswLe6PoAxA). ## Product Hunt started as a Linkydink group Product Hunt began in November 2013 with a Linkydink group. In [his launch announcement](https://www.ryanhoover.me/post/announcing-product-hunt), 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. ![Product Hunt's archived Linkydink group with November 2013 product links, contributor portraits, and a Subscribe button.](https://sarthakmishra.com/assets/product-hunt-linkydink-2013-BXhCK-ro.jpeg) Product Hunt’s Linkydink group, rendered from the [November 9, 2013 Internet Archive capture](https://web.archive.org/web/20131109095046/http://linkydink.io:80/groups/product-hunt). Linkydink handled link collection and the daily email, but Hoover wanted [a place to discuss those discoveries](https://medium.com/on-startups/the-artifacts-of-product-hunt-11682e9e01dd). Building the custom site meant designing product-submission fields, voting controls, and a way to read and write comments. Cofounder Nathan Bashaw’s [account](https://medium.com/lets-make-things/the-origin-of-product-hunt-7acb09e2593a) describes making names and taglines easy to scan and opening discussions in a side pane. ![Product Hunt's December 2013 website, with product rankings at left and an Assembly discussion pane open at right.](https://sarthakmishra.com/assets/product-hunt-website-2013-esadtEra.jpeg) Product Hunt’s website and discussion pane in December 2013. Original screenshot from [Ryan Hoover’s account of its interaction design](https://www.ryanhoover.me/post/hunting-for-habits-keying-in-on-smart-design-to-make-a-product-irresistible). Hoover and Bashaw [kept Linkydink’s grouping of products by day](https://medium.com/lets-make-things/the-origin-of-product-hunt-7acb09e2593a) 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. | Question | What it changes in the scope | | ---------------------------------------------------------- | ------------------------------------------------------------------------------------------ | | What does the first user need to understand or accomplish? | The behavior, content, and interaction that deserve attention first. | | What can a prototype let you observe? | What to test before building a live flow, and what still needs testing with real use. | | Which work can the team handle personally? | Which automation to defer, who owns that work, and the limit on what the team can promise. | | How much help will the first user have? | The setup, instructions, support, and recovery paths needed for that audience. | 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](https://sarthakmishra.com/blog/how-startups-designed-their-mvps#inquiry) 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. ## Structured data ```json { "@context": "https://schema.org", "@graph": [ { "@type": "WebSite", "@id": "https://sarthakmishra.com/#website", "url": "https://sarthakmishra.com/", "name": "Sarthak Mishra", "publisher": { "@id": "https://sarthakmishra.com/#person" }, "inLanguage": "en" }, { "@type": "Person", "@id": "https://sarthakmishra.com/#person", "name": "Sarthak Mishra", "url": "https://sarthakmishra.com/about", "jobTitle": "Design Engineer", "image": "https://sarthakmishra.com/og-images/sarthak-mishra.webp", "sameAs": [ "https://github.com/SarthakMishra", "https://www.linkedin.com/in/itssarthakmishra/", "https://x.com/MishraMishry" ] }, { "@type": "WebPage", "@id": "https://sarthakmishra.com/blog/how-startups-designed-their-mvps#webpage", "url": "https://sarthakmishra.com/blog/how-startups-designed-their-mvps", "name": "How Dropbox, DoorDash, Airbnb and Stripe designed their MVPs", "description": "Early UI and founder stories from Dropbox, DoorDash, Airbnb, Stripe, Zapier, and Product Hunt. What to design first, reuse, and leave for later.", "inLanguage": "en", "isPartOf": { "@id": "https://sarthakmishra.com/#website" }, "mainEntity": { "@id": "https://sarthakmishra.com/blog/how-startups-designed-their-mvps#content" }, "breadcrumb": { "@id": "https://sarthakmishra.com/blog/how-startups-designed-their-mvps#breadcrumb" } }, { "@id": "https://sarthakmishra.com/blog/how-startups-designed-their-mvps#content", "url": "https://sarthakmishra.com/blog/how-startups-designed-their-mvps", "name": "How Dropbox, DoorDash, Airbnb and Stripe designed their MVPs", "description": "Early UI and founder stories from Dropbox, DoorDash, Airbnb, Stripe, Zapier, and Product Hunt. What to design first, reuse, and leave for later.", "mainEntityOfPage": { "@id": "https://sarthakmishra.com/blog/how-startups-designed-their-mvps#webpage" }, "author": { "@id": "https://sarthakmishra.com/#person" }, "datePublished": "2026-11-03T00:00:00.000Z", "inLanguage": "en", "keywords": [ "saas", "mvp", "product-design", "prototyping", "user-experience", "y-combinator" ], "@type": "BlogPosting", "headline": "How Dropbox, DoorDash, Airbnb and Stripe designed their MVPs", "publisher": { "@id": "https://sarthakmishra.com/#person" }, "image": "https://sarthakmishra.com/og-images/blog/how-startups-designed-their-mvps.webp" }, { "@type": "BreadcrumbList", "@id": "https://sarthakmishra.com/blog/how-startups-designed-their-mvps#breadcrumb", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://sarthakmishra.com/" }, { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://sarthakmishra.com/blog" }, { "@type": "ListItem", "position": 3, "name": "How Dropbox, DoorDash, Airbnb and Stripe designed their MVPs", "item": "https://sarthakmishra.com/blog/how-startups-designed-their-mvps" } ] } ] } ```