How to Solve the Cold Start Problem in a Two-Sided Marketplace (Real Tactics, Not Theory)
The cold start problem in a two-sided marketplace is solved by picking one side first, subsidizing or manually fulfilling it yourself, and proving the transaction in a single geography before scaling. Most successful marketplace founders operated as concierge services before they built true platform automation. RaftLabs builds marketplace platforms for founders who have proven their transaction manually and are ready to scale the technology.
Key Takeaways
- Pick one side first. Seed it manually, overpay if necessary. Never subsidize both sides at once.
- Constrain geography. One city, one category, one vertical. Prove 1,000 successful transactions before expanding.
- Treat early-stage as a concierge service, not a marketplace. The platform comes after the transaction is proven.
- The engineering mistake is building complex matching before manual matching works. Ship the simplest possible matchmaking first.
Every marketplace founder hits the same wall on day one. You've built the platform. You've got the idea. And nobody is there.
Not because the idea is bad. Because supply won't show up without demand, and demand won't show up without supply. This is the cold start problem. It's not a marketing challenge or a product challenge. It's a structural challenge baked into the model itself.
The good news: it's solvable. But not with what most founders try first. Not with a polished platform, a national launch, or a "growth hack." The founders who cracked it did something unglamorous. They cheated. They picked one side, subsidized it, and manually held the other side together until the flywheel had enough momentum to turn on its own.
Here's what that actually looked like, from founders who did it.
The Core Problem: Why Both Sides Won't Move First
A two-sided marketplace has a structural dependency. Supply needs demand to participate. Demand needs supply to see value. Neither side will commit first without proof the other side exists.
This creates a simple but brutal trap:
| Side | What they need | What they won't do |
|---|---|---|
| Buyers | Enough sellers to browse and transact | Pay or return if the catalog is empty |
| Sellers | Enough buyers to make listing worthwhile | Invest time building a profile nobody sees |
The trap tightens with every failed launch attempt. If buyers show up and find no sellers, they leave and don't return. If sellers list and get no orders, they stop maintaining their profiles. Each failure makes the next launch harder.
The founders who broke this loop understood something counterintuitive: you don't launch a marketplace. You pretend to be one while manually holding it together underneath.
The 4 Failure Modes That Kill Marketplaces Before They Start
Most marketplace failures are predictable. The same patterns show up repeatedly.
1. Subsidizing Both Sides at Once
The instinct is to solve the chicken-and-egg problem by offering deals to both buyers and sellers simultaneously. Discount for buyers. Free listings for sellers. Heavy referral bonuses on both ends.
This burns cash without building a flywheel. You're acquiring users on both sides who have no reason to transact with each other. When the subsidies stop, both sides leave. You've bought attention, not a marketplace.
The correct approach: pick one side. Fund it heavily until the other side has a reason to show up organically.
2. Launching Nationally Before One City Works
Geographic spread feels like progress. It isn't. A marketplace that covers 50 cities with 3 sellers each is not a marketplace. It's a broken product in 50 locations.
Supply density matters more than supply count. 100 sellers in one city creates a usable marketplace. 100 sellers across the country creates a search result with no conversions.
The Prosper model was explicit about this: focus on ONE region. Hit 1,000 successful transactions there before expanding anywhere else. That number gives you enough data to know whether your matching logic, pricing, and supply quality are working.
3. Building Complex Matching Before Manual Matching Is Proven
Engineering teams default to their strongest suit. That often means building sophisticated recommendation engines, AI-powered matching, and dynamic pricing algorithms before anyone has actually transacted on the platform.
The problem: you don't know what signals matter until you've watched real transactions fail and succeed. The algorithm you build in advance will optimize for the wrong variables. You'll spend three months building a system that confidently suggests the wrong match, faster.
The Infura co-founder's observation applies here directly: early-stage platforms operate as concierge services, not true marketplaces. The technology should follow the proven transaction, not precede it.
4. Underpricing Supply to Win Sellers Early
Attracting sellers with below-market rates feels smart. More sellers means more supply density, which attracts buyers. The problem is that low pricing attracts low-quality providers.
When buyers transact with underpriced, low-quality sellers, they leave and don't return. The supply side looks full, but the quality is too low to retain demand. You've optimized for quantity at the cost of conversion.
Prosper's co-founder took the opposite approach: overpay reliable providers initially. Pay above market to get quality supply locked in. Then charge buyers a price that reflects that quality. The early economics don't work, but the trust signal does.
What the Right Approach Looks Like
The founders who solved cold start didn't wait for the platform to work. They made it work manually first.
Pick one side and subsidize it heavily. Not both. One. The side that's harder to acquire is usually supply. Identify 20 to 50 high-quality providers in your target category, in your target city, and pay them more than market rate to be available. Don't automate this. Call them, meet them, onboard them manually.
Operate as a concierge service. YC-backed Backpack's approach was direct: start with real demand first, then fulfill the orders yourself if necessary. Founders doing the fulfillment manually. Not because the platform couldn't do it, but because the platform didn't need to exist yet. The goal was proving the transaction, not proving the software.
LogoTournament took the same path at a different scale. They seeded the platform with trusted designers before opening to the public. Then they manually hosted contests and matched clients with designers one by one. They acquired customers through targeted advertising even when early conversion was low. The $25M GMV they built came from years of manual operations that only looked like a platform from the outside.
Never expand geography until one market is working. "Working" has a specific definition: 1,000 successful transactions with consistent conversion rates, return rates above baseline, and supply quality holding steady. Before that number, you don't have data. You have anecdotes.
Build the simplest possible matchmaking first. A table. A spreadsheet. A form submission that routes to a human who makes the match. Automate what's proven. Build the algorithm after you know which inputs actually predict a successful transaction.
The consensus across every marketplace founder who cracked this: "You need to cheat to kickstart one side." Either incentivize early adopters heavily or provide one side yourself. Both are forms of the same thing: making the marketplace look functional before it is.
How RaftLabs Approaches Marketplace Platforms
We've built marketplace infrastructure for founders across services, logistics, B2B wholesale, and professional services. The pattern is consistent.
The founders who succeed come to us after they've proven the transaction manually. They know their supply density, their conversion rate, and their pricing model. They've done the concierge work. Now they need the platform to do what they've been doing by hand.
That's the right order. Platform-first founders ask us to build matching logic before they know what the match looks like. Concierge-first founders ask us to automate a transaction they understand completely.
We start every marketplace engagement with a scoping call to map the transaction that's already working. We identify the manual steps, the trust signals, the failure modes, and the quality indicators. Then we build the platform layer that systematizes what's already proven.
The result is a marketplace that works at launch because the transaction was proven before the code was written.
If you've done the manual work and you're ready to build the platform, book a 30-minute scoping call with our team.
Sources
The Cold Start Problem, by Andrew Chen (2021) — covers platform bootstrapping, liquidity tactics, and the atomic network concept
YC Startup School: How to Get Users (2023) — founders doing things that don't scale, manual fulfillment, demand-first sequencing
LogoTournament founder interview via Indie Hackers (2019) — seeding with trusted designers, manual contest hosting, $25M GMV milestone
Prosper marketplace founding story via TechCrunch (2006) — single region focus, quality supply subsidy, 1,000-transaction threshold
a16z Marketplace 100 (2024) — annual analysis of marketplace growth patterns and supply-demand dynamics across categories
Frequently asked questions
- The cold start problem is the chicken-and-egg dilemma every marketplace faces at launch. Without enough supply, buyers see no value and don't return. Without buyers, sellers have no reason to join. Both sides need the other to exist before either one will commit. Breaking this requires choosing one side to seed first, often manually or with heavy incentives.
- The right answer depends on which side is harder to acquire. In most marketplaces, supply is the constraint. Seed the supply side first, even if you overpay or fulfill it yourself. Once supply is visible and reliable, buyers follow. Subsidizing both sides simultaneously burns cash with no flywheel effect.
- The benchmark cited by Prosper's co-founder is 1,000 successful transactions in a single market. Before that number, you don't know if your matching logic works, your pricing is right, or your supply is reliable. Geographic expansion before hitting that benchmark just spreads the problem without fixing it.
- No. Most successful marketplace founders ran concierge operations before they automated anything. The job in the early stage is to prove that the transaction works, not to prove that the software works. Build the simplest possible matchmaking interface first. Automate what's proven later.
- The four most common failures are: subsidizing both sides simultaneously instead of picking one; launching nationally before one city works; building complex matching algorithms before manual matching is proven; and underpricing supply to win sellers, which attracts low-quality providers and tanks buyer trust.
- RaftLabs builds the platform infrastructure after founders have proven their transaction manually. That means marketplace backend architecture, matching logic, payment rails, and supplier/buyer portals. We start with a scoping call to understand the transaction that's already working and build from there.
Ask an AI
Get an instant summary of this post from your preferred AI assistant.
Related articles
Why Two-Sided Marketplaces Fail: The Liquidity Problem Nobody Warns You About
Most marketplace founders obsess over the cold start problem. The real killer is what happens after you have users. This is the liquidity trap and how to avoid it.
How to Choose a Custom Software Development Company
You've got 5 vendor proposals on your desk and no way to compare them — here's the evaluation framework that actually works.
6 Types of AI Agents for Business (2026 Buyer's Guide)
AI agents aren't one thing. Here are the 6 types every business decision-maker should understand — and how to know which one you actually need.