TL;DR: A marketplace is the one product category where a finished, working build can still be worth nothing, because the value is created by other users and on launch day there aren't any. Building the software is the predictable part. The hard parts are the cold start (which side do you fill first, and how narrow do you go), trust (which is a feature set, not a policy page), money movement (holds, splits, refunds, leakage), and matching (the layer that quietly is the product). Here's how we scope two-sided builds, what belongs in v1, and the questions to answer before anyone writes code.
Most marketplace projects arrive fully imagined. There's a buyer app, a seller app, an admin panel, ratings, chat, payments, promo codes, a referral program and a dispute flow. It's a coherent picture, and it's usually a picture of a marketplace that already works, drawn by someone standing at year three looking back.
The problem is that a marketplace on day one is not a smaller version of that. It's an empty room. A social app with no friends is boring; a marketplace with no supply is broken, because a user who shows up and finds nothing to buy does not come back to check whether you fixed it. That single difference should reshape what you build first, and it usually doesn't.
We've built two-sided products where the hard part sat somewhere different each time, and the pattern below is what we now push on before quoting a build.
What makes a marketplace different from ordinary software
With most software, you control whether the product works. If the invoicing tool calculates correctly and loads fast, it delivers its value on its own. A vertical SaaS build for a business you already run is like this: the value is in the system, and the system is yours.
A marketplace hands that control away. Your product's job is to make a transaction happen between two parties, and you supply neither side of it. What you're really building is the conditions for that transaction: enough of the right supply, enough trust for a stranger to commit, a way to find the right match, and a way to move money safely. The interface is the smallest part.
This has a practical consequence for scoping. In normal software, feature completeness is a reasonable v1 goal. In a marketplace, feature completeness on an empty platform is the single most common way to spend a full budget and learn nothing.
The cold start: pick a side, then go embarrassingly narrow
Every marketplace faces the same opening problem. Buyers won't come without sellers, and sellers won't stay without buyers. There are only a few honest ways through it, and none of them is a feature.
Decide which side is constrained. In most marketplaces it's supply. Demand for a real need usually exists already; what's missing is enough available, reliable supply to serve it. Fill that side first, manually if necessary, and accept that it looks nothing like a scalable growth plan. It isn't meant to. It's meant to make the first hundred transactions possible.
Go far narrower than feels comfortable. Liquidity is local, not global. A thousand users spread across a country is a dead marketplace; a hundred users in one city, one campus, one category or one building is a live one. Narrowing is not a smaller ambition, it's the only way to reach the density where the product works at all, and it's the same discipline we push for any 0-to-1 launch.
Do the unscalable things on purpose. Recruit early supply by hand. Match the first transactions yourself. Run the thin side as a concierge service behind a simple interface. Every early marketplace that worked did some version of this, and it's cheaper than the alternative, which is building automation for a volume you don't have yet.
Measure liquidity, not signups. The number that tells you whether a marketplace is alive is the share of demand that gets fulfilled: what percentage of requests find a match, how long a match takes, how often supply sits idle. Signups and downloads can look excellent while the actual market is failing. Instrument the match rate from day one, because it's the metric that tells you whether to expand or to narrow further.
Trust is a feature set, not a policy page
Marketplaces ask strangers to take a risk with each other: to pay before receiving, to let someone into their home, to get into a car. The amount of trust the transaction demands should directly drive how much of your budget goes to safety, and this is the line item founders most often discover late.
Covoisino is a clear example from our own work. It's a ride-sharing app for hitchhikers, and it exists specifically to make hitchhiking safer by preventing theft and other crimes. Safety wasn't a compliance checkbox bolted on at the end, it was the reason the product had a right to exist, which is why QR verification sits at the center of the flow rather than in a settings menu. When the risk is that high, trust mechanics are the product and the listings are the wrapper.
The building blocks are worth naming, because they're where scope grows:
- Identity and verification. How sure do you need to be that a person is who they claim to be, and what proof is proportionate to the risk? Verifying a photo is a different build from verifying a licence, an insurance document or a business registration.
- Reputation that survives gaming. Ratings only mean something if they're tied to completed transactions and hard to farm. Review systems are easy to build and easy to build badly.
- Communication inside the platform. Keeping conversations in-app protects both sides, gives you evidence in a dispute and reduces the chance the deal walks off your platform entirely.
- A dispute and escalation path. Something will go wrong in the first month. Decide who reviews it, what evidence exists, and what the resolution options are before it happens, not during.
- Real-time safety, if the transaction is physical. Sharing a trip, an emergency action, a check-in. Physical marketplaces carry obligations digital ones don't.
Ask any studio quoting your marketplace which of those five are in scope. If trust and safety appear as a single line, the estimate is not real.
Money is where the complexity actually lives
Taking a card payment is easy. Being the party in the middle of somebody else's transaction is not, and this is where marketplace builds outgrow their estimates.
You have to decide when money is captured and when it's released, since holding funds until delivery is confirmed is what protects the buyer and is also a materially larger build than a simple charge. You need split payouts, a payout schedule, and a way to handle the days when the two sides of your ledger disagree. Refunds, cancellations and partial fulfilment each need a defined path. If your sellers are businesses, onboarding them into a payments provider brings verification requirements that add real time to the build, and it's better to discover that in week one than in week six.
Then there's the take rate, which is the strategic version of the same problem. Charge too little and the marketplace can't fund itself; charge too much and both sides have an incentive to meet once on your platform and transact off it forever. That leakage, sometimes called disintermediation, is not solved by terms and conditions. It's solved by making the platform genuinely more convenient than going around it: the payment protection, the reputation, the scheduling, the dispute cover, the repeat discovery. If the only thing you provide is an introduction, you will be routed around.
The matching layer is the product
Users describe marketplaces by their listings, but what they actually pay for is a good match arriving quickly. That layer deserves more design attention than anything else in the app.
Some marketplaces are search-and-browse, where the buyer chooses. Some are request-and-dispatch, where the platform assigns. Many are a mix, and the choice changes the entire experience: a browse marketplace lives or dies on filters, ranking and listing quality, while a dispatch marketplace lives or dies on response time and coverage. Getting this wrong is expensive, because it isn't a UI decision, it's the operating model.
This is also the most natural place for AI in a two-sided product: ranking and relevance, cleaning messy seller-supplied listings, first-pass moderation of content and images, summarizing disputes for a human reviewer, routing requests intelligently. We build custom AI agents into products where they remove real operational load, and marketplace operations, where a small team drowns in review queues as volume grows, is one of the clearest cases for it.
Not every two-sided product looks like a marketplace
Sometimes the two sides exist, but the hard problem is infrastructure rather than an interface. Geonode's Repocket SDKs, which we built as custom cross-platform SDKs, let users earn by sharing internet bandwidth while customers get global residential proxy coverage. Both sides are real, but almost none of the difficulty is in a listings page. It's in the SDK across platforms, the reliability of distributed supply, and the plumbing that keeps the network dependable enough to sell.
That's worth checking before you commission a marketplace app. If your supply side is software rather than people, you may be building an SDK and infrastructure product with a marketplace attached, and the budget belongs in a very different place.
What belongs in v1
The version that teaches you something is smaller than the one in the pitch deck. In practice, a first marketplace release needs: one narrow segment or geography, the constrained side onboarded (by hand if needed), a listing or request flow, the matching mechanism you've chosen, payments with whatever protection the risk level demands, the minimum trust mechanics for that risk, and instrumentation on the match rate.
What can wait: the second category, the second city, native apps on both platforms if one covers your first segment, the referral program, promo codes, advanced seller analytics, and most of the admin panel, because at low volume you are the admin panel. We break down how to price and size a first release in our MVP cost guide, and the same lever applies here: scope is the budget, and the discipline is writing down what you are deliberately not building.
AI-native delivery has genuinely changed the build side of this. Senior engineers working with AI coding agents compress what used to be a months-long two-sided build into a far shorter cycle, which is how we ship in days rather than months. What it has not changed is liquidity. Being able to build the marketplace faster is only an advantage if you use the time you saved to solve the cold start.
How we scope a marketplace build
- Name both sides precisely. Who supplies, who buys, and what one successful transaction looks like end to end.
- Identify the constrained side and the plan to fill it. If there's no answer beyond "marketing," the build is premature.
- Set the geography or category boundary for v1. Deliberately small, written down.
- Rate the trust requirement honestly. The risk in the transaction sets the verification, reputation and safety scope, and therefore a large share of the budget.
- Decide the money flow before design. Capture, hold, release, split, refund, and the take rate that funds the business without inviting leakage.
- Instrument the match rate on day one. Fulfilment, not signups, tells you whether it's working.
Buyer checklist
Before you commission a marketplace from anyone, get these answers.
- Ask which side they think is constrained, and what the plan is for filling it before launch.
- Get the v1 boundary in writing: one segment, one geography, one category.
- Ask them to walk through the money flow, including holds, splits, refunds and failed payouts.
- Confirm trust and safety are itemized, not a single line, and that the scope matches the real-world risk.
- Ask what the match rate is expected to be, and confirm it's instrumented before launch.
- Ask what stops both sides going around you after the first transaction, and whether the answer is a feature or a hope.
A marketplace is the highest-leverage software category there is, and the least forgiving. The build is the part we can promise; the liquidity is the part we scope you toward instead of around. If a partner quotes you a full-featured two-sided platform without asking which side is constrained, they're pricing a product, not a market.
Thinking about a marketplace or another two-sided product? Book a demo and we'll scope it honestly, including whether a narrower v1 or a different product shape gets you there faster. See our work: Covoisino, Geonode's Repocket SDKs, Fyuel and 40+ products shipped worldwide.