Marketplace Cold Start: How Do You Make the First Match?
Solve a marketplace cold start one fulfilled request at a time. Learn from FreeeUp and Sourcewiz without confusing SaaS sales with marketplace liquidity.
A marketplace has a cold-start problem when buyers cannot find suitable supply and suppliers cannot see enough real demand to participate. Adding registrations on both sides does not necessarily solve it. You need one small market in which a specific request can actually be fulfilled.
Start with the first match, not the eventual network diagram. This guide uses two founder accounts to separate useful standalone software, human matching, and evidence of a working marketplace. The goal is a repeatable transaction or fulfilled request whose outcome you can inspect.
Contents
What is missing when both sides wait?
Usually the missing resource is relevant, available participation at the moment a user needs it. A large catalog is not helpful if its sellers cannot perform the requested job, and a long buyer list is not useful if nobody has an active requirement.
In Stripe's interview with Andrew Chen, the cold-start challenge is described as a network that can shrink before reaching useful density: buyers leave when there is insufficient supply, and suppliers leave when demand is absent. The practical response is to reduce the problem to a market you can serve.
Define the first matching cell by job, buyer, supplier capability, and delivery constraints. For example, “an ecommerce operator needs a product-image edit this week” is more actionable than “businesses need freelancers.” The example describes a possible cell, not demand we have measured.
Use the existing beachhead-market guide to choose the first buyer group. This article addresses the next, different question: how does that buyer actually encounter available supply and receive the promised outcome?
Should you begin with a service or a useful tool?
Begin with whichever delivers value before the network is large. A managed service can complete early matches manually; a standalone tool can earn adoption without requiring the other side to participate immediately.
Chen's Stripe discussion uses Hipcamp's camping discovery utility and OpenTable's restaurant tooling to explain different starting sides. The transferable idea is useful independent value, not that every marketplace should copy either company.
| Starting route | Immediate value | Evidence still needed |
|---|---|---|
| Managed matching | Someone finds an available, suitable provider | Fulfilled requests and repeat demand |
| Supplier software | A provider completes its own workflow | Buyers will transact through the network |
| Buyer utility | A buyer discovers or organizes relevant options | Those options become actionable supply |
A paid standalone product can succeed even if the marketplace never develops. That can be a valid outcome. Keep its revenue and the marketplace's transaction evidence separate rather than claiming a network is working because software subscriptions exist.
If the main question is who pays and what the platform charges for, use the marketplace business-model guide. Fee design and solving the first match are related decisions with different evidence requirements.
What do FreeeUp and Sourcewiz show?
FreeeUp describes curated introductions backed by people and screening. Sourcewiz describes selling manufacturer workflow software while exploring marketplace demand. They illustrate different starting mechanisms; neither account supplies a controlled experiment proving one route superior.
In the FreeeUp interview, Connor Gillivan describes roughly 700 freelancers after about 18 months and introductions usually made within 24 hours. Those are historical founder claims, not present-day service guarantees. The project record preserves the founder-reported evidence grade.
The useful detail is what the operator does between a request and an introduction. Screening, understanding requirements, and responding when a match fails are part of the delivered value. Seven hundred names alone would not establish that a buyer's particular job can be filled.
In Sourcewiz's interview, Divyaanshu Makkar describes spending four to five months visiting roughly 100 factories before developing the product. The account later discusses approximately 400 paid customers and $200,000–$250,000 ARR, alongside marketplace experiments. These are founder-reported historical figures.
The Sourcewiz record links the software to catalogs, quotations, and manufacturing sales workflows. Its subscription traction cannot be silently converted into marketplace liquidity or transaction volume. The distinction is the central lesson of this case.
Together, the accounts suggest a disciplined question: which part of the first customer outcome can you deliver now, and which network behavior remains unproven? Retain both answers when comparing opportunities.
How do you run the first matching cell?
Define one request type, recruit capable and currently available supply, and track the result of each real request. The first experiment should produce an operating ledger, not a large-looking directory.
Use this sequence:
- 1.Specify the job, required inputs, deadline, and acceptance condition.
- 2.Verify that suppliers can perform that job and have agreed to participate.
- 3.Ask buyers for actual requests within the defined boundary.
- 4.Make the introduction or manage fulfillment with everyone's role clear.
- 5.Record completion, failure, delay, and support effort.
- 6.Ask whether the buyer would use the route again for the same need.
This is a proposed operating method. FreeeUp's historical account supports the importance of screening and introductions; it does not verify your suppliers or guarantee your turnaround time.
Keep a compact ledger:
| Field | What to record | Why it matters |
|---|---|---|
| Request | Actual job and constraints | Defines the relevant market |
| Supply offered | Qualified, available providers | Separates usable supply from listings |
| Outcome | Completed, declined, expired, or failed | Shows whether the match worked |
| Timing | Request-to-introduction and completion | Exposes where users wait |
| Intervention | Operator minutes and exceptions | Reveals the service burden |
| Repeat signal | A later real request or confirmed intent | Separates satisfaction from durable demand |
A hypothetical example makes the denominator problem clear. Suppose twelve requests arrive, eight fit the declared scope, six receive introductions, and four complete. Report all four counts. “Four completions” alone hides the rejected requests; “50% completion” needs the eight in-scope requests identified as its denominator. These are invented planning numbers, not a benchmark.
Do not list suppliers as available without their agreement or publish fictitious transactions to make the network look active. Manual work can bridge an early gap; misleading availability cannot establish trust.
Which signals justify expanding the market?
Expand when the existing cell repeatedly fulfills relevant demand and the operating effort is supportable. More categories or locations can dilute useful density if the original cell still fails ordinary requests.
Look for repeated completion, supplier responsiveness, buyer return, and manageable intervention. Separate seasonal activity and one enthusiastic customer from a pattern across independent users. There is no universal number of listings that proves readiness.
Sourcewiz's account is a reminder to preserve distinct scorecards: customers paying for a workflow tool are one signal; buyers and suppliers transacting through a marketplace are another. Measure both if you operate both.
A network effect is a further hypothesis. The software-moat guide asks whether additional participation actually improves outcomes rather than merely increasing account count. If the model depends on an outside software provider, the white-label operating checklist can help identify responsibilities you still retain.
Before widening the market, inspect the original FreeeUp and Sourcewiz records. Write down the work performed before the impressive milestone. That work is more useful for planning your first match than copying the milestone itself.
Frequently Asked Questions
Should a marketplace recruit buyers or suppliers first?
Start with the side that lets you deliver useful value in the chosen market. Availability constraints, existing relationships, and standalone utility matter more than a universal supply-first or demand-first rule.
Does a large waitlist solve cold start?
No. A waitlist records interest. You still need relevant requests, available supply, successful fulfillment, and evidence that participants return when they have the same need again.
Can manual matching count as a real marketplace test?
Yes, if roles are clear and actual requests are fulfilled. Record the human effort so successful service delivery is not mistaken for proof that a self-service system already works.
Does SaaS revenue prove marketplace traction?
No. A supplier can pay for useful software without receiving buyers through a network. Keep subscription revenue, marketplace transactions, and fulfilled matches separate when interpreting a case.