# Get a marketplace to its first completed transactions First 1000 publishes a public search API over its indexed pages; the guide is at https://www.first1000.co/agent-access. Source: https://www.first1000.co/blog/marketplace-first-transactions Source observed: 2026-10-08T01:42:30.112Z Last checked: 2026-10-08T01:42:30.112+00:00 Indexed: 2026-10-08T01:43:44.315+00:00 --- # Get a marketplace to its first completed transactions **First 1000 field note · Updated October 7, 2026** **By Ali Abouelatta · Synthesis: October 7, 2026** Get the first transaction small enough to watch. We would rather learn why five orders failed than collect another hundred emails without knowing what anyone wanted. ## Choose the transaction before the channel The [DoorDash case](https://www.first1000.co/blog/doordash-first-200-orders) starts with delivery orders that a business could not fulfill. Its founders delivered the first 200 orders themselves. The [Uber case](https://www.first1000.co/blog/uber-first-customers) includes a December 2010 dispatch failure that assigned drivers to multiple riders. [Airbnb's case](https://www.first1000.co/blog/airbnb) describes a first lodging experiment that fit inside a single apartment during a design conference. 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. | Your constraint | First move | Evidence to collect | | --- | --- | --- | | Buyers arrive but cannot find a match | Recruit usable supply for one narrow request | Match rate, time to fulfillment, reason for each failed request | | Supply exists but receives no relevant requests | Find a concentrated buyer group with the specific need | Qualified requests per reachable buyer; completed transactions | | You do not know what fulfillment requires | Perform a small batch manually, where you can do so safely | Operator time, cost, failures, and customer feedback per transaction | | Both sides have a reason to act around one event | Limit the launch to that place and deadline | Available supply against expected requests; actual completion | ## Use the cases for different decisions [DoorDash](https://www.first1000.co/blog/doordash-first-200-orders) is useful when you are tempted to build dispatch software before completing the job. Its 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](https://www.first1000.co/blog/uber-first-customers) 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](https://www.first1000.co/blog/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 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. **Fictional repair-marketplace example:** four founder-hours are available on Saturday, one hour is needed for setup and overruns, and each job takes 45 minutes to coordinate and inspect. That leaves room for four jobs. A waiting list can extend 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 we 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, repair types accepted, available slots, price or quoting process, and booking method. It should also say what happens when a 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, 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 our 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](https://www.first1000.co/blog/doordash-first-200-orders) - [Uber: early acquisition and a dispatch failure](https://www.first1000.co/blog/uber-first-customers) - [Airbnb: event-bounded marketplace tests](https://www.first1000.co/blog/airbnb) This is an editorial synthesis of the linked First 1000 cases. Historical actions belong to those accounts; the decision table and test brief are recommendations, not measured causal findings. Updated October 7, 2026. Based on original First 1000 reporting and the sources listed above. --- [Read this page’s summary](https://www.first1000.co/api/public/v1/page-tldr?url=https%3A%2F%2Fwww.first1000.co%2Fblog%2Fmarketplace-first-transactions&trace=t_dae5763819f4) ## Ask a follow-up about this page Need a more specific answer? Ask the exact question you have. It returns a fresh, cited answer from First 1000’s knowledge base. No account or API key required. Open this URL with your own question, URL-encoded. Only q is required. No account or setup. `GET https://www.first1000.co/agent/faq?q={question}&trace=t_dae5763819f4` [Tool guide and examples](https://www.first1000.co/agent-access) · [OpenAPI](https://www.first1000.co/api/public/v1/openapi.json) · [Page TLDR form](https://www.first1000.co/agent-tools/page-tldr?url=https%3A%2F%2Fwww.first1000.co%2Fblog%2Fmarketplace-first-transactions). Opening a form does not execute a tool.