Marketplace

How to Build a Two-Sided Marketplace

8 min readAbsolute Foundry

A two-sided marketplace connects supply and demand — sellers and buyers, hosts and guests, pros and clients — and takes a cut for making the match. The software is the easy half. The hard half is liquidity: having enough of both sides that each finds the other fast. Build for that, or the prettiest marketplace stays empty.

When someone pitches us a marketplace, we spend less time on the feature list and more on a single question: how do you survive the cold start? Here's how we think it through.

01 The cold-start problem comes before the code

No buyers come without sellers; no sellers stay without buyers. We don't try to launch both sides everywhere at once — that's how marketplaces die thin. We pick one narrow niche or city, over-serve one side first (usually the harder-to-get supply), and make the product feel full in that slice before expanding.

The trade-off we weighedLaunch broad vs. dominate a niche. Going wide feels ambitious and spreads liquidity so thin that neither side has a good first experience. Going narrow feels small and is how nearly every great marketplace actually started. We always start narrow — a single category or geography dense enough that the first buyers reliably find the first sellers — then expand from a position of density.

02 Where you sit on payments and trust is the business

The platform's real value is removing risk from a transaction between strangers. So we design those rails deliberately:

Payments through the platform (Stripe Connect or similar) so you can hold funds, take your cut, and pay out — not let the two sides settle off-platform.
Trust signals — verification, reviews, dispute handling — built in, because a bad first transaction kills word of mouth.
Escrow or delayed payout where the stakes justify it, so buyers feel safe and sellers get paid.

This is also your defence against disintermediation — the moment both sides take the deal off your platform, you're a directory, not a marketplace.

03 Build the matching, not just the listings

A marketplace isn't a list of listings; it's a matching engine. Search, ranking, filters and (later) recommendations are the product. Early on we keep matching simple and even manual where it helps — concierge-matching the first transactions by hand teaches you what to automate.

04 Measure liquidity, not vanity

Sign-ups don't matter; matches do. We instrument the one metric that predicts survival — the share of demand that successfully transacts (and how fast) — and build every iteration to move it. A marketplace with great liquidity in a small niche beats a huge empty one every time.

Where we'd landStart narrow and dense, own payments and trust on-platform, treat matching as the product, and obsess over liquidity (matches), not sign-ups. Expand only once a slice is genuinely liquid.

Key takeaways

Solve the cold start first — go narrow and dense, seed the harder side.
Take payments and trust on-platform; it's your value and your moat.
Matching (search/ranking) is the product, not the listings.
Measure liquidity — successful matches — not sign-ups.

FAQ

Which side do we seed first?

Usually the harder-to-acquire side (often supply), so that when demand arrives it finds a full-feeling marketplace.

Should payments go through the platform?

Almost always yes — it's how you monetise, build trust, and avoid the two sides cutting you out.

Can you build payments, trust and the app?

Yes — from build to payment rails and product design, end to end.

We build marketplaces designed for liquidity, not just listings.

Build my marketplace