The DoorDash MVP: A Landing Page, a Phone and Four Cars

TL;DR

The DoorDash MVP was a website called PaloAltoDelivery.com. It took about an hour to put up in January 2013. It had a handful of restaurant menus saved as PDFs, a Google Voice phone number, and a flat $6 delivery fee. The first order, Thai food, came in within half an hour. Four Stanford students took the calls, placed the orders with the restaurant, and drove the food over themselves, between classes, using Square to take payment, a Google Doc to track orders and Find My Friends to see where the other drivers were.

They ran it that way for six months. When they applied to Y Combinator they had done 217 deliveries and still had no app. Eleven years later the company was worth $70 billion at IPO and now handles more than half of all food delivery in the United States.

That is the whole story of the MVP. The rest of this post is the detail: what they validated and how, what each tool replaced, the numbers at every step, and what a founder with a service or marketplace idea can copy from it in 2026 without spending a dollar on software first.

What people mean when they say “the DoorDash MVP”

There is a version of every famous startup’s origin story that is mostly legend, and a version that the founders themselves have told in enough detail to check. DoorDash is rare because it has the second kind. Stanley Tang has told it on his own blog and in talks; Evan Moore told it in interviews around the IPO; the Stanford Daily reported on the company in September 2013 while it was still four founders and thirty drivers. The dates and numbers below come from those accounts and they agree with each other.

“The DoorDash MVP” refers to the period from January 2013, when PaloAltoDelivery.com went live, to roughly the summer of 2013, when the company joined Y Combinator, renamed itself and hired its first drivers. During those months the product was not software. It was a landing page and a group of people doing the job by hand.

That makes it the textbook concierge MVP: the founders personally delivered the service the software would eventually deliver, and learned the business by doing it. It is worth being precise about this, because the lesson of DoorDash is not “build a food delivery app fast”. It is “find out whether anyone wants food delivered before you build anything at all”.

The problem they found before the idea

The idea did not start with food. In the autumn of 2012, Stanley Tang, Andy Fang, Tony Xu and Evan Moore were Stanford students working on technology for small business owners, and they were walking around downtown Palo Alto showing an early app to shopkeepers and asking what actually hurt.

One of those conversations was with Chloe, who owned a macaron shop called Chantal Guillon on University Avenue. Tang has described what happened next: she pulled out a thick booklet, pages and pages of delivery orders she had turned down. She had no drivers and no way to fulfil them, and she was the one doing everything in the shop already.

Moore has called that the lightbulb moment, if there was one: why couldn’t a small business send things across town on demand?

What they did with the moment is the part most founders skip. They did not go home and start building. Over the following weeks they talked to somewhere between 150 and 200 other small business owners in the area and asked the same question. Restaurants in particular kept saying the same thing: delivery was a headache they wanted and could not manage, because drivers were expensive to keep on staff and impossible to schedule around demand that spiked twice a day.

So by the time they had an idea, they also had a stack of evidence that the problem was real, specific and shared. That is the step that idea validation exists to force, and DoorDash did it with a notebook and a few weeks of walking.

The three hypotheses

Moore has been explicit that before launching anything, the four of them wrote down what had to be true for the business to work. There were three hypotheses.

Excess consumer demand exists. People in Palo Alto want food delivered from restaurants that do not currently deliver, and there are enough of them to matter. Moore called this the most important one: if it was false, nothing else mattered.
Restaurants want this. Restaurants without delivery will take orders from a third party and hand food to a stranger’s driver.
The delivery economics work. Someone can be paid to drive the food over, the customer will pay a fee that covers it, and the numbers close.

Everything about the MVP that followed was designed to test hypothesis one as cheaply as possible, while gathering signal on two and three as a side effect. That framing is what separates a concierge MVP from just doing a job by hand. They were not running a delivery business. They were running an experiment that looked like a delivery business.

The landing page existed to test one hypothesis. Doing the deliveries themselves answered the other two for free.

What PaloAltoDelivery.com actually was

In January 2013 they registered the domain paloaltodelivery.com. The name was chosen because it was what someone in Palo Alto would type into Google, which is as close as the MVP got to a marketing strategy.

The site, by every founder account, took about an hour to put up. One afternoon at most. Here is the complete feature list.

A landing page saying that Palo Alto Delivery would bring food from local restaurants to your door.
A handful of restaurant menus, uploaded as PDF files. Not a menu database. Not a search. Files.
A phone number. It was a Google Voice number that rang the founders’ own mobile phones.
A flat delivery fee of $6, which was the company’s only revenue.

There was no ordering form. You looked at a PDF, decided what you wanted, and called. There was no account, no app, no map, no driver tracking, no payment page, no dispatch. Tang has put it plainly: they launched in about an hour, with no drivers and no algorithms.

If you have ever been told your MVP needs a login system before it can launch, this is the counter-example. The DoorDash MVP could not have passed a code review because there was almost no code.

The first order, and the first week

The first call came within about thirty minutes of the site going live. It was an order for Thai food. Evan Moore took the call and the founders went and got it. He has described running out of class repeatedly in those first weeks to answer the phone, because the phone was the product.

Within a week they were doing around ten orders a day. There was no launch event and no marketing spend. Tony Xu sent an email to Stanford dorms. They printed flyers and handed them out on University Avenue. The rest was Google, which is why the domain name mattered, and word of mouth, which in a college town with no other option moves fast.

Every new customer got a personal email from one of the founders asking how it went. That is not a nicety. It is the feedback loop the whole MVP existed to run, and it cost nothing.

The stack: what each tool replaced

The reason DoorDash is such a clean example is that every piece of a delivery platform existed in the MVP, just not as software. Here is what did each job.

The job a delivery platform does	What DoorDash used in early 2013	What it costs
Show customers what they can order	PDF menus on a landing page	$0
Take the order	A Google Voice number ringing four phones	$0
Take payment	Square, card reader on a phone	Transaction fee only
Track orders and status	A shared Google Doc	$0
Dispatch a driver	Whoever was free, decided out loud	$0
Know where the drivers are	Apple’s Find My Friends	$0
Deliver the food	The founders, in their own cars	Petrol
Collect feedback	A personal email to every customer	Time
Marketing	The domain name, flyers, one dorm email	Printing

Look at what is not on that list: developers, servers, a mobile app, a merchant integration, a driver app, a routing algorithm, a payments integration. Every one of those became necessary later. None of them was necessary to find out whether hypothesis one was true.

This is the piecemeal MVP pattern taken to its limit: existing consumer tools glued together by people, standing in for a product that did not exist yet. The difference between this and a Wizard of Oz MVP is that customers knew a person was doing it; the site said as much. Nobody was pretending there was an algorithm.

Every component of the platform was present in the MVP. None of it was code.

Six months of doing it by hand

This is the part of the story that gets compressed into a sentence and should not be. The founders ran Palo Alto Delivery manually from January to roughly June 2013, while still being students.

Deliveries happened in two windows that fitted around classes: 12:00 to 1:30 and 5:30 to 8:00. Outside those hours the service did not exist. That constraint, which sounds like a weakness, was a feature of the experiment: lunch and dinner are when demand spikes, so the two windows captured most of the signal with a quarter of the effort.

The founders personally did the first couple of hundred deliveries. Several accounts put the number at around 200 before anyone else drove. By the time they applied to Y Combinator, about six months after launch, the count was 217 deliveries, and they still did not have an app.

Moore has said, with some self-awareness, that they probably took Paul Graham’s “do things that don’t scale” advice too far. But consider what those six months taught them that no amount of software would have:

How long a delivery actually takes door to door in Palo Alto, and therefore what a driver costs per drop.
Which restaurants were happy to hand food to a stranger and which ones made a fuss, and why.
What customers complained about (cold food, wrong items, timing), which became the first features that mattered.
How demand behaved hour by hour, which is the input every dispatch algorithm they later wrote depended on.
Whether $6 was too much, too little or about right. It was about right, and they kept it for years.

Tang has said that doing things that don’t scale is one of a founder’s biggest competitive advantages, because the hands-on work teaches you the fundamentals you need in order to build the real systems later. That is the argument for a concierge MVP in one sentence, and it comes from someone who did 200 deliveries to earn the right to say it.

Summer 2013: Y Combinator and the first real numbers

They applied to YC for the summer 2013 batch on the strength of 217 hand-delivered orders and a landing page. Paul Buchheit, the YC partner who interviewed them, was reportedly sceptical at first and came round as he watched the numbers move. They were accepted and received $120,000 for 7 percent of the company. In June 2013 they incorporated as DoorDash; the name Palo Alto Delivery would not have survived a second city.

The Stanford Daily profiled the company in September 2013, and that article is the best snapshot of what the MVP had become eight months in:

Cities: Palo Alto and Mountain View.
Restaurants: more than 60.
Drivers: grew from 4 (the founders) to about 30 over the summer, roughly half of them Stanford students, recruited through Craigslist, flyers and, in at least one case, by approaching pizza delivery drivers on the street. Drivers used their own car, insurance and fuel and were paid $14 an hour plus tips.
Fee: $6 flat for orders under $100, $12 above that.
Delivery time: within 45 minutes.
Growth: orders up roughly ten times over the summer, with almost no campus presence because it was the holidays.

That summer is also when the first software appeared: online ordering, and a way for drivers to pick up shifts from a phone. Notice the order of events. Software arrived after the demand was proven, after the economics were measured by hand, and after the operational problems were understood well enough to know what to automate first. The app was built to remove the founders from a loop that already worked, not to find out whether the loop existed.

The company raised a $2.4 million seed round led by Khosla Ventures in September 2013 and a $17.3 million Series A from Sequoia in May 2014. It expanded to Los Angeles in October 2014. It went public in December 2020 at a valuation of about $71 billion and today handles more than half of US food delivery. None of that is the MVP, and none of it needs more than this paragraph here.

Everything left of the bracket is the MVP. The first real code shipped in the summer, once there was nothing left to learn by hand.

What the DoorDash MVP validated, in order

It is tempting to say “they validated the idea”. They validated four specific things, and the order matters because each one was cheaper than the next.

1. That the problem existed on the supply side

Before the site, from the interviews. Restaurants wanted delivery and could not run it. Cost: a few weeks of conversations.

2. That demand existed on the consumer side

From the first thirty minutes, then the first week. People in Palo Alto would look at a PDF and phone a stranger to bring them Thai food for $6. Cost: an hour of work and a domain.

3. That the unit economics could close

From doing the deliveries. They knew, from their own driving, how many drops an hour a driver could do, and therefore that $14 an hour plus tips against $6 a delivery could work at reasonable density. Cost: their own evenings for six months.

4. That it could be run by people who were not founders

From the summer. Thirty drivers on their own cars, half of them students, with a phone-based shift system. If that had failed, DoorDash would be a very good Palo Alto delivery service run by four people. Cost: the YC money.

Only after all four did it make sense to spend on the product most founders would have started with. This is also the sequence investors reconstruct when they look at an MVP: what did you learn, what did it cost to learn it, and what did you deliberately not build yet. There is a full breakdown of that in how investors evaluate an MVP.

Why it worked, and where the legend gets it wrong

It worked because the problem was already validated

The one-hour landing page gets the attention, but the two months of walking University Avenue talking to shop owners is why the landing page worked. They put up a page for a problem 200 people had already told them they had. A founder who copies the hour and skips the two months is running a different, much worse experiment.

It worked because the manual version was a real business

This is the thing that makes food delivery, and services in general, unusually good candidates for a concierge MVP. The manual version was not a simulation of the product; it was the product, at small scale. Customers got real food, delivered. The founders got real revenue, $6 at a time. Compare this with a software product where the manual version is someone typing results into a spreadsheet: still useful, but the customer is getting a demo of the value rather than the value itself. The foodtech MVP and marketplace MVP guides go into why this holds for on-demand services in particular.

It worked because they charged from day one

The $6 fee was not a monetisation decision made later. It was in the MVP from the first order, which meant hypothesis one was “will people pay for this”, not “will people click on this”. A free MVP would have produced more orders and less information.

It worked because they measured with their own hands

Every number that later fed an algorithm, from delivery time to demand curves to driver cost, came from the founders having done the job. The software they eventually built automated a process they understood completely. That is the opposite of the usual failure mode, where a team builds a dispatch system for a delivery pattern it has never seen.

Where the legend gets it wrong

The legend says DoorDash was “built in an hour”. The site was. The MVP took six months, most of it in cars. The legend also implies the founders had a product vision from the start; by their own account they had a problem, three hypotheses and a phone number, and the vision arrived in the doing. And the legend rarely mentions that they applied to YC with no app and got in anyway, which is the single most useful fact in the story for a founder wondering whether they need to build before they can raise. Do you need an MVP to raise funding covers that question properly; the DoorDash answer was 217 deliveries and a Google Doc.

DoorDash next to Uber and Airbnb

The three most-cited marketplace MVPs took three different routes, and the differences are instructive.

	Uber	Airbnb	DoorDash
First version	An iPhone app, one city, one button, black cars only	A page renting air mattresses in the founders’ apartment during a conference	A landing page with PDF menus and a phone number
Software at launch	Real app, small scope	Basic website	Almost none
Who did the work	Contracted drivers	The founders, as hosts	The founders, as drivers
First hypothesis	Will people summon a car from a phone?	Will strangers pay to sleep in someone’s home?	Will people pay $6 to get food delivered?
Time to first software	Day one	Day one, minimal	About six months

Uber had to write software because the value was in the summoning; a phone number would have been a taxi dispatch. Airbnb needed a listing to exist online because the transaction was between strangers who had to find each other. DoorDash’s value was food arriving, and a phone call delivers that as well as an app does. The rule that falls out: build software only for the part of the value that cannot be delivered by a person on a phone. For most service and marketplace ideas that part is smaller than founders think. The wider set of cases is in MVP examples.

How to copy the DoorDash MVP in 2026

The tools have changed and the method has not. If you have an idea for a service, an on-demand product or a local marketplace, here is the DoorDash playbook translated to now. Nothing on this list requires a developer.

Week 1 and 2: find your booklet

Talk to the supply side first, in person if it is local. You are looking for the equivalent of Chloe’s booklet: evidence that the problem is already costing someone money or orders they can point to. Twenty conversations is a floor; DoorDash did ten times that. Write down the three things that must be true for your idea to work, and rank them. The one you cannot afford to be wrong about is the one your MVP tests.

Week 3: put up the page

One page, built in an afternoon with a site builder. State what you do, for whom, and the price. Include a phone number or a WhatsApp number that reaches you, not a form that reaches a database. Include the price; a free MVP tests curiosity, a priced one tests demand. Use a domain name that is what your customer would search for. The landing page MVP guide has the layout; the DoorDash lesson is that the page can be uglier than you think as long as the number works.

Week 3 onward: do the job yourself

Take the calls. Deliver the service. Use Stripe or Square for payment, a shared spreadsheet for orders, a group chat for dispatch, your phone’s location sharing for tracking. Fix your hours to the windows when demand peaks. Email or message every customer afterwards and ask what went wrong. Keep a tally of the numbers that will one day become an algorithm: how long each job takes, what it costs, when demand arrives.

The threshold for building anything

Build software when, and only when, you are the bottleneck. DoorDash’s first code was online ordering and driver shifts, because the founders taking calls and driving was what capped growth. If you are not yet the bottleneck, you have not yet learned enough to know what to automate. Once you are, the build is a different job, scoped by six months of evidence rather than by a features list, and that is the point at which a rapid MVP build makes sense.

What to do with the numbers

By the time you build, you should be able to say: this many people, paying this much, this often, with this cost to serve, and here is the one thing we cannot do by hand any more. That sentence is worth more to an investor than any prototype, and it is worth more to your development team than any specification. The MVP validation guide covers how to turn a manual run into evidence a build can be scoped from.

DoorDash spent six months in the third box. Most founders start in the fourth.

When the DoorDash approach does not apply

A concierge MVP is not universal, and pretending otherwise is how founders waste a summer.

When the value is the software itself. If your idea is a tool, an analytics product, an AI feature, the manual version is a demo of the output rather than the product. It still tells you something, but it cannot tell you whether people will use the software, because there is no software. A prototype or a thin working version answers that; a phone number does not.

When the manual version does not resemble the real economics. DoorDash’s $6 fee and founder-driven deliveries were a small version of the real model. If your manual version is only possible because you are subsidising it with your time in a way no employee ever could, you are testing demand for something you cannot actually sell. Be honest about which numbers will survive the transition to paid staff.

When trust requires a product. Anything involving money movement, health data or identity usually needs the real thing before a customer will engage, because the customer is evaluating the system, not the service. There is no concierge version of a bank.

When you are not local. Palo Alto Delivery worked because four people could physically cover the whole market. A marketplace that has to be national from day one cannot be run from a Google Doc, which is why it needs a different first step: usually one city, or one category, with the same manual approach applied there.

What happens after the concierge phase

Founders who run a DoorDash-style MVP well tend to arrive at the same moment: the manual process works, the numbers are real, and the founders are now the thing that stops it growing. That is the point at which the build begins, and it is a very different build from the one they would have started with, because it is scoped from evidence.

What usually gets built first is the ordering flow (to stop taking calls), the dispatch (to stop deciding out loud) and the supply-side tool (so the restaurants, drivers or providers can manage themselves). What gets built later is everything else. The how to build an MVP guide covers scoping that first version, and how much an MVP costs puts numbers on it. A first version built after a concierge phase is typically smaller and cheaper than one built cold, because half the feature list has already been proven unnecessary.

The other thing that happens is that the first build does not last. DoorDash rebuilt its stack more than once as it scaled; the summer 2013 ordering system was not what ran the company in 2016. That is normal and it is not waste. The guides on when to rebuild your MVP and production-ready MVPs cover the transition. The manual phase buys you the knowledge to build the first version right; it does not buy you a version that never changes.

Conclusion

The DoorDash MVP was a landing page, some PDFs, a phone number and four people in cars. It went up in an hour, took its first order in thirty minutes, and ran for six months before a line of real product code was written. In that time it validated demand, supply and unit economics with about $0 of software spend, and produced the 217 deliveries that got a company with no app into Y Combinator.

The transferable lesson is not the speed. It is the order: find the problem, write down what has to be true, test the most important thing with the cheapest possible instrument, do the job by hand until you are the bottleneck, and only then build. Most founders reverse that order, build first and learn last, and the build ends up scoped by imagination instead of by 200 deliveries.

If you have a service or marketplace idea and are working out how little to build before you know, that is the conversation we have most weeks as an MVP development company: sometimes the answer is a build, and often the answer is a phone number first. Start it here.

Frequently Asked Questions

What was the DoorDash MVP?

A website called PaloAltoDelivery.com, launched in January 2013 by four Stanford students. It had a handful of restaurant menus as PDF files, a Google Voice phone number and a flat $6 delivery fee. Customers called in orders; the founders placed them with the restaurant and delivered the food themselves. There was no app, no online ordering and no dispatch software for about six months.

How long did it take to build the DoorDash MVP?

About an hour, by Stanley Tang’s account, or one afternoon by the Stanford Daily’s. The domain was registered, a one-page site went up with PDF menus and a phone number, and the first order came in within roughly thirty minutes.

Was DoorDash a concierge MVP?

Yes, and it is probably the clearest example of one. The founders personally performed the service the software would later automate: taking calls, placing orders, driving deliveries, collecting payment with Square and tracking everything in a Google Doc. Customers knew people were doing it; nobody pretended there was an algorithm.

How many deliveries did the DoorDash founders do themselves?

Around 200 in the first months, by most accounts. When they applied to Y Combinator about six months after launch, they had completed 217 deliveries in total and still had no app. The four founders were the only drivers until the summer of 2013.

How much did DoorDash charge in its MVP?

A flat $6 delivery fee from the first order, which was the company’s only revenue. By September 2013 it was $6 for orders under $100 and $12 above that. Charging from day one meant the MVP tested willingness to pay, not just interest.

What tools did DoorDash use before it had an app?

A landing page with PDF menus, a Google Voice number that rang the founders’ phones, Square for card payments, a shared Google Doc for order tracking, Apple’s Find My Friends to see where drivers were, and the founders’ own cars. Marketing was the domain name, printed flyers on University Avenue and one email to Stanford dorms.

Did DoorDash have an app when it got into Y Combinator?

No. They were accepted into the summer 2013 batch, receiving $120,000 for 7 percent, on the strength of 217 hand-delivered orders and a landing page. The first online ordering and driver shift software was built during that summer.

What did the DoorDash MVP validate?

Four things, in order: that restaurants had a delivery problem (from 150 to 200 interviews before launch), that consumers would pay for delivery (from the first week of orders), that the unit economics could work (from doing the deliveries and timing them), and that non-founders could run it (from scaling to 30 drivers in summer 2013).

When did DoorDash build its first real software?

In the summer of 2013, after joining Y Combinator, roughly six months after launch. The first pieces were online ordering and a phone-based way for drivers to pick up shifts, built specifically to remove the founders from a process that already worked.

Can a founder copy the DoorDash MVP today?

For a service, on-demand or local marketplace idea, yes, almost step for step: interview the supply side, write down the three things that must be true, put up a one-page site with a price and a number that reaches you, do the job by hand with Stripe, a spreadsheet and a group chat, and build software only once you are the bottleneck. It does not translate to products where the value is the software itself, where trust requires a real system, or where the manual economics would never survive paid staff.