Get a marketplace to its first completed transactions

Choose the transaction before the channel

The DoorDash case starts with delivery orders that a business could not fulfill. Its founders delivered the first 200 orders themselves. The Uber case includes a December 2010 dispatch failure that assigned drivers to multiple riders. Airbnb's first lodging experiment fit inside a single apartment during a design conference.

I would use these cases to choose the size of the first market. One neighborhood, service window, or event gives you something you can inspect. A nationwide signup form does not tell you whether buyers and sellers can complete the exchange.

Use the cases for different decisions

DoorDash is useful when you are tempted to build dispatch software before completing the job. The early service used a phone number and delivery windows that fit around the founders' classes. Manual fulfillment exposed the work the software would later need to support.

Uber is useful when a promotion could overwhelm supply. Its early credits and referrals gave people a reason to try a ride, but the dispatch failure shows why acquiring demand and serving it have to be examined together. The historical sources do not provide a channel-by-channel ledger of the first 1,000 riders.

Airbnb is useful when you need a reason for both sides to act now. The conference created a temporary accommodation constraint. Treat the event as a test boundary; do not assume that demand during one crowded weekend will persist the following month.

Set capacity before promising a service window

For a founder-run service, estimate capacity from the work itself. Subtract setup and recovery time from the hours you have available, then divide the remaining time by the observed time per transaction. If transactions overlap, include the bottleneck that still has to happen one at a time. This is a planning limit, not a demand forecast.

For example, a fictional repair marketplace has four founder-hours available on Saturday, needs one hour for setup and overruns, and takes 45 minutes to coordinate and inspect each job. That leaves room for four jobs. Accept a waiting list beyond that if it helps you learn, but promise only the slots you can support. After Saturday, replace the estimate with the actual work and failures.

Then choose one way to reach those buyers. DoorDash used dorm outreach and search for a local delivery need. Airbnb used an event with constrained accommodation. For your test, write the equivalent as a sentence: people in this place need this service before this date, and I can reach them here. If the sentence ends with everyone on social media, narrow it.

Ask for the transaction you can fulfill

For the fictional repair service, a useful offer would name the area, the repair types accepted, the available slots, the price or quoting process, and how to request a booking. It should also say what happens when the job falls outside that scope. A general invitation to join the future of home services tests something else.

Record which offer each request came from. For a request you cannot fulfill, keep the reason: wrong location, no available supplier, unacceptable price, timing, or a job outside scope. Those failures tell you whether to change distribution, recruit a different supplier, or change the offer. More promotion is a poor fix for a calendar you cannot serve.

Write a first-transaction brief

Before another feature, I would fill in five lines: who needs the exchange, what supply is available, where and when the promise applies, what counts as completion, and who handles a failure. If one line is blank, the next task is usually obvious.

1. Name one buyer request and the supplier who can satisfy it.
2. Set a place, service window, and capacity the team can support.
3. Choose a reachable distribution channel for that specific request.
4. Log completed and failed transactions, operator time, refunds, and the customer's account of what happened.
5. Decide what failure or repeated manual step would justify the next product change.

Check whether the transaction survives the incentive

A discounted first order can test willingness to try. It cannot establish willingness to return at the regular price. Keep incentive costs and repeat transactions visible, and compare customers who have had enough time to return.

These cases are selected historical accounts, not an experiment proving one launch strategy wins. The checklist is my interpretation. Use it to choose a test that can fail clearly, then keep the actual result beside the plan.

A practical stop rule is a service promise you cannot keep safely or economically. Pause the offer, inspect the failed transactions, and change one cause before restarting. Keep the signup list; stop treating its growth as evidence that the marketplace works.

Sources and original research

• DoorDash: first 200 orders
• Uber: early acquisition and a dispatch failure
• Airbnb: event-bounded marketplace tests

Editorial synthesis of the linked First 1000 cases. Historical actions are attributed to those accounts; the decision table and test brief are recommendations, not measured causal findings.