The First 200 Orders Were the Product

Start with the operator's pain

A small-business owner named Chloe showed the founders a thick booklet of delivery orders. She had no drivers to fulfill them and was doing the work herself.

That is a better starting point than “food delivery is a big market.” The team saw a specific operator with a repeated problem and then spent the next few months learning the system around it. Tony Xu signed up to drive for delivery platforms. The founders also interviewed roughly 150–200 small-business owners.

The interviews were not a substitute for shipping. They helped the team understand the ugly operating details: driver schedules on paper, managers calling to confirm shifts, and too many or too few drivers even in a business already delivering at scale.

The MVP was a phone number

After that learning period, the team launched a first MVP in a few hours. The site did not have online booking. A customer called a phone number that was just one founder's mobile phone. There was no dispatch system or backend, and they did not recruit drivers.

They listed the times when they could deliver between classes. They also put restaurants on the site without first building a complicated restaurant workflow.

That is not a product recommendation for every marketplace. It is a useful question for an early one: what is the smallest version of the transaction you need to complete so you can learn whether the problem is real?

The founders called the site PaloAltoDelivery.com because they wanted to be found by people searching for Palo Alto delivery. The first phone call arrived about half an hour after launch, for a Thai-food order.

The next 199 orders stayed manual

For the first 200 orders, the founders delivered everything themselves. They used two windows that fit around their classes: 12:00–1:30 p.m. and 5:30–8:00 p.m. There was no hired dasher team hidden behind the story.

They sent an email to Stanford dorms, then combined that with organic search. After each delivery, they manually emailed customers to ask how it went and how they heard about the service. The follow-up was specific: if somebody ordered chicken skewers from Oren's Hummus, the founders could ask about that meal instead of sending a survey that sounded like a database.

That feedback loop did three jobs at once. It revealed whether the delivery happened, showed where the customer came from, and made an early customer feel known. Those relationships later turned customers into advocates.

The founder decision

The distinction from a software-first MVP matters. Stripe's early case is about installing software into a customer's environment; this case is about personally completing the promised transaction. When I would copy this pattern, I would write down four boundaries before building more infrastructure.

The founders did not need a dispatch system to learn what a completed delivery required. They needed enough real orders to see the failure modes and decide what infrastructure would remove them.

The four boundaries

• What is the completed job? A signup is not a delivery. Name the moment the customer receives the promised value.
• Can the founding team perform it for a small, explicit batch? Doing the work may reveal failure modes faster than building a general system.
• What will each customer teach you? Ask where they came from, what happened, and what almost went wrong.
• What evidence ends the manual phase? A queue, repeated failure, or service window may justify automation. “It feels more professional” is not a measurement.

Sources and original research

• Original First 1000 case study: DoorDash, December 3, 2020

This is an attributed adaptation of the December 3, 2020 DoorDash case study. The historical actions and counts come from Ali's original account; the checklist is editorial adaptation. The source does not provide a verified channel mix, retention rate, revenue result, or current DoorDash operating metrics.