Two-sided marketplace: what to build first (and what to fake)
A founder pitched me his idea over coffee last spring. “It’s the Airbnb for commercial kitchens,” he said. Restaurants with idle kitchen space on one side, food entrepreneurs who need a licensed kitchen on the other. He had the supply lined up, a designer mock-up, and a quote from a dev shop. What he didn’t have was an answer when I asked the only question that mattered: on launch day, with zero kitchens listed and zero cooks signed up, what does anyone see when they open the app?
He’d been sold the build. Nobody had told him about the problem every two-sided marketplace presents, the one the build doesn’t solve.
A two-sided marketplace is a platform whose value comes from connecting two distinct groups who need each other, one supplying something and the other demanding it, where the product’s whole job is to make matches and take a cut of the transaction. Airbnb connects hosts and guests. Uber connects drivers and riders. Etsy connects makers and buyers. The founder builds neither the supply nor the demand. He builds the machine in the middle and earns a fee every time it works.
That definition sounds simple, and it hides the two things that sink most marketplace founders. The first: you are not building one product. The second: the software is the easy part.
What a two-sided marketplace actually is
“The Uber for X” is a great pitch and a terrible spec. It compresses three separate products into one familiar word and makes the founder think he’s building an app. He’s building three things.
There’s the supply-side product: how a kitchen owner lists their space, sets availability, prices it, and gets paid. There’s the demand-side product: how a cook searches, compares, books, and pays. And there’s the matching engine in between: the logic that decides which kitchens a given cook sees, in what order, filtered by what, ranked by what. The two sides barely share a screen. A host’s experience of Airbnb and a guest’s experience of Airbnb are almost entirely different software that happen to live behind the same logo.
This is why a marketplace costs more to build than a single product and why it is the wrong shape for a true minimum viable product in the usual sense. You can’t ship half a marketplace. A booking flow with nothing to book is a demo, not a product. Both sides have to exist, at least in skeleton, before anyone can use the thing once.
The only problem that actually kills marketplaces
Here is the part the economics textbooks and the platform-vendor sales pages both skip. An empty marketplace is worthless to everyone. No cook joins a kitchen-rental app with no kitchens. No kitchen owner lists space on an app with no cooks. Each side is waiting for the other, and the founder is standing in the middle with a beautifully built product that does nothing.
This is the cold-start problem, and it is the single most reliable cause of marketplace death. Andrew Chen, who spent years on growth at Uber, wrote an entire book about it for a reason: most marketplaces never reach the point where both sides show up on their own. The technology was never the bottleneck. Liquidity was, the simple condition where a buyer who arrives can reliably find a seller and vice versa.
The rule that follows is not intuitive for a founder who just paid for a two-sided product: don’t launch two-sided. Pick the harder side, usually supply, and build it up first, by hand if you have to, until there’s enough there that the other side has a reason to arrive. Airbnb’s founders photographed listings themselves. DoorDash started as a static page with a few local restaurant menus and a phone number that rang the founders. The marketplace came later. The manual hustle came first.
If a dev shop quotes you a marketplace build and never once mentions liquidity or the cold start, they’re selling you the easy half and leaving you to discover the hard half alone.
Examples that teach the real lesson
Yes, Etsy is a two-sided marketplace (makers and buyers). Yes, Zillow is one, though a messier one, since it connects buyers, sellers, agents, and its own data products, which makes it closer to a multi-sided platform. The useful examples aren’t the famous logos, though. They’re the launches.
The lesson in every marketplace that worked is that it found a way to be useful to one side before the other side existed. Some had a “single-player mode”: a tool that helped the supply side even with zero demand. OpenTable gave restaurants reservation-management software they wanted anyway, then turned that installed base into the supply side of a diner-facing marketplace. The software earned its keep on one side first. The network came as a second act.
For a founder, the question that flows from this isn’t “what’s my Uber for X.” It’s “what can I give one side that’s valuable even while the other side is empty.” If you can’t answer that, you don’t have a cold-start plan, and a marketplace without a cold-start plan is a very expensive way to learn about liquidity.
What software a marketplace actually needs
Strip the romance and a marketplace is four systems. Naming them lets you brief a build instead of gesturing at Uber.
Two onboarding-and-listing surfaces, one per side. The supply side needs to create and manage whatever they’re offering; the demand side needs to create an account and express what they want. These are mostly standard. Plenty of marketplaces start here on no-code.
A discovery and matching layer. This is search, filtering, ranking, and the rules that decide who sees whom. This is also where your actual product lives. The difference between a marketplace that feels magical and one that feels like a spreadsheet is almost entirely in the matching, and it’s the one part that’s specific to your business.
A trust layer. Reviews, verification, dispute handling, and whatever your category needs to make a stranger comfortable transacting with another stranger. In a kitchen-rental app this might mean license verification and insurance. In a babysitting app it’s background checks. Trust is not a feature you add later; in many categories it is the product.
Payments, and usually escrow. The marketplace takes money from one side, holds it, and releases it to the other after the transaction, minus its cut. This is more involved than a normal checkout because you’re moving money between two users, often with a delay and a dispute window. Stripe and others offer building blocks for this, but the policy, who gets paid when, what happens on a cancellation, is yours to decide.
Notice the pattern: two of the four systems are mostly generic, and two of them, matching and trust, are where your defensibility lives. That has a direct consequence for the next decision.
Build it, rent a platform, or go custom
You have three honest options, and the right one depends entirely on how standard your matching and trust need to be.
A marketplace platform like Sharetribe or a similar tool gets you a working two-sided marketplace fast, with listings, search, and payments out of the box. This is the marketplace equivalent of building on a white-label product: excellent for validating that the two sides will actually show up, constrained the moment your matching or trust logic needs to be non-standard. If your marketplace is “Airbnb but for a niche” with conventional search and conventional reviews, a platform may carry you further than founders expect.
A no-code or low-code build sits in the middle and works for the same reason a platform does, until the matching engine you really need fights the tool you chose.
A custom build is the right call when the matching or the trust layer is your edge, when the thing that makes your marketplace better than the obvious incumbent is specifically how you connect the two sides or how you make them trust each other. You don’t go custom to save money. You go custom to own the one part you can’t afford to rent. (This is the same build-versus-buy logic that applies to any software decision, sharpened by the fact that a marketplace has an obvious generic core and a narrow defensible center.)
The expensive mistake is going custom on the generic 80% and treating the matching logic as an afterthought. We’ve watched founders spend their budget rebuilding listing forms and search bars that a platform gives away, then run out of money before they ever built the matching that was supposed to be the whole point.
What to build first, and what to fake
Start with the side you’ll have to drag into existence, and build the least software that lets you serve it by hand. A founder validating a marketplace does not need an automated matching engine on day one. He needs a first version that proves the two sides will transact, and the matching can be a human, often the founder, reading both lists and making the connection over email.
This is the concierge approach, and for marketplaces it’s not a shortcut, it’s the correct first build. Manual matching teaches you the matching rules you’ll eventually automate, the rules no dev shop can guess for you. You learn that cooks care more about square footage than location, or the reverse, by doing it by hand fifty times. Then you build the engine that encodes what you learned, and you build it custom, because by then you know it’s the part worth owning.
The commercial-kitchen founder went back to his dev shop and changed the order. Supply side first, listings he entered himself, matching done by him over WhatsApp for the first two months. The custom build came after he had thirty kitchens and a waitlist of cooks, when he finally knew what the matching engine actually had to do. The app he ended up with cost less than the one he’d been quoted, and unlike that one, it had something to match.
Frequently asked questions
What is a two-sided marketplace?
A two-sided marketplace is a platform whose value comes from connecting two distinct groups who need each other, one supplying something and the other demanding it, where the product’s whole job is to make matches and take a cut of the transaction. Airbnb connects hosts and guests, Uber connects drivers and riders, Etsy connects makers and buyers. The founder builds neither side; he builds the matching machine in the middle and earns a fee every time it works.
What is an example of a two-sided marketplace?
Airbnb (hosts and guests), Uber (drivers and riders), Etsy (sellers and buyers), and DoorDash (restaurants and diners) are all two-sided marketplaces. The instructive part isn’t the famous logo, it’s how each one launched: every one found a way to be useful to one side before the other side existed, usually by building up supply manually before demand arrived.
Is Etsy a two-sided marketplace?
Yes. Etsy connects two distinct groups, independent makers on the supply side and buyers looking for handmade or vintage goods on the demand side, and takes a cut of each sale. Like most marketplaces it solved supply first, attracting sellers and their inventory before it had a large buyer base to offer them.
Is Zillow a two-sided marketplace?
Sort of, and it’s a useful edge case. Zillow connects buyers, sellers, and agents, and runs its own data products on top, which makes it closer to a multi-sided platform than a clean two-sided one. Many real marketplaces drift this way as they grow; the two-sided model is the starting mental model, not always the final shape.
How do you build a two-sided marketplace?
Don’t launch two-sided. Pick the harder side (usually supply), build it up first (by hand if necessary) until there’s enough there that the other side has a reason to arrive, then turn on demand. Start with the least software that lets you serve one side and match by hand, learn the matching rules manually, then build the matching and trust layers custom because that’s where your defensibility lives. The listing surfaces and payments are mostly generic; the matching and trust are not.
What is the two-sided market theory?
It’s the economics concept that some platforms create value by serving two interdependent customer groups at once, where each group’s value grows with the size of the other (a network effect), and pricing one side can subsidize the other. It’s useful background, but it’s an economist’s frame; the founder’s problem is the practical one of getting either side to show up first.