Liquidity first: the order marketplace model problems actually arrive in

A marketplace is not a business until it is liquid. Before that it is two mailing lists that do not know about each other, and no amount of clever monetization design changes it. This is why marketplace planning that starts with the take rate almost always ends badly: the revenue model is the last decision, not the first.

Here is the order the problems actually arrive: liquidity, then who pays, then what the fee is paying for, then the ways a marketplace leaks, and finally the point when the honest move is to stop being a marketplace.

What to take away

• The choice is narrower than it looks: the supply side, the demand side, both, or somebody else entirely who wants access to one of them.
• Take rate is a definition: the platform's revenue divided by the value transacted through it.
• Some markets support marketplaces and some do not, and it is largely decided before you start.
• Marketplaces do not own the cost of what is sold, which makes their contribution margin on paper look unlike a business that does.

Liquidity is the product

Liquidity is not a feeling about traffic. It is measurable, and it is measurable from either side.

From the supply side: of the listings, offers, or availability posted in a period, what fraction transact before they expire or are withdrawn. From the demand side: of the people who searched with real intent, what fraction found something they were willing to transact on, and how long it took them.

Both numbers matter and they fail differently. How to compute each without flattering yourself is set out in unit economics.

Supply-side liquidity that is too low means sellers stop showing up, and they leave quietly, without telling you. Demand-side liquidity that is too low means buyers form the habit of checking somewhere else first. Habits are far harder to recover than accounts.

The trap in both is averaging. Liquidity is local: to a category, a city, a price band, a date range, a skill. A platform can be liquid in aggregate and dead in every individual slice a real user cares about, and the aggregate will keep reporting health while the users leave.

The cold start, done honestly

Only one side is genuinely constrained. Work out which, because the entire early strategy follows from it.

The constrained side is scarce, hard to substitute, and has somewhere else to go. If your suppliers are already busy and turning down work, demand is not your problem. If your buyers have three other places to look, supply is not your problem.

Getting this backwards means spending the first year recruiting the side that would have arrived on its own.

Three approaches that are structurally sound, as opposed to the ones that just inflate a number.

Constrain the market until it is dense. One city, one category, one niche narrow enough that a participant sees real choice on their first visit. A thin national marketplace is worse than a dense local one, because a first visit that finds nothing is the only impression most people ever form.

Pay for the hard side directly. Subsidy is legitimate when it buys presence in a market that becomes self-sustaining. It is a bridge, and it needs a written end condition: the local density at which the subsidy stops. Without that condition, the subsidy becomes the business model and no one notices for years.

Be the supply. Owning inventory, employing the providers, or fulfilling the early demand yourself is not cheating. It gives buyers a reason to arrive before independent supply exists, and it teaches you the operational detail you will need to write the rules later. The cost is that it is capital-intensive and hard to unwind.

Who pays

The choice is narrower than it looks: the supply side, the demand side, both, or somebody else entirely who wants access to one of them.

Charging supply is the common default, and it works when suppliers gain access to demand they could not reach themselves. It breaks down when suppliers can reach that demand directly, at which point your fee reads as a tax on a relationship they already had.

Charging demand works when buyers are getting something they visibly cannot assemble alone: selection, comparison, safety, speed. It is harder in markets where buyers are conditioned to believe search is free, and it makes price comparison against a direct alternative brutally simple.

Charging both is defensible when both sides get something distinct, and it doubles the number of people who can decide your fee is too high.

Charging a third party (advertising, placement, data), separates the money from the transaction. That relieves pressure on the fee and creates a permanent tension, because whoever pays eventually influences what gets shown, and the ranking is the product.

The side that captures more surplus from a match should pay more of the fee. The side with more alternatives will resist harder, no matter what it captures.

The economics of matching, search, and fees on electronic markets is covered in MIT's course on economics and e-commerce. When those forces point opposite ways, you have your model's hardest decision.

What a take rate is actually paying for

Take rate is a definition: the platform's revenue divided by the value transacted through it. It has no correct value, and nothing you read about someone else's tells you anything about yours. Where the fee should sit inside a wider structure is a pricing architecture question rather than a benchmark one.

What determines it is the list of jobs you genuinely perform. Discovery and matching. Trust between strangers. Payment handling and its risk. Dispute resolution and recourse. Demand generation. Quality enforcement. Scheduling, logistics, or anything else you actually operate.

Two useful constructions, neither requiring a benchmark. First: for each job on that list, ask what a participant would pay a third party to do it, or what it would cost in time to do themselves. The sum bounds what your fee can be worth.

Second: ask what a participant loses by going around you. If the honest answer is "nothing much", your take rate is not too high, your service list is too short.

A take rate under pressure is a message about the service list, and it is usually answered in the wrong place. Raising enforcement effort to defend a fee that is not earning its keep buys you a year and a reputation.

Where a marketplace leaks

Disintermediation is normal, not a betrayal. Two parties who have met, done business successfully, and expect to do it again have every reason to take the next transaction off your rails. If you provide nothing on the second transaction that you provided on the first, they are right.

A leak audit worth running, in order:

• At what point in the flow do the two sides get each other's contact details, and what did you get in return for that?
• Which of your services are consumed only once (introduction, verification, first payment), and which are consumed every time?
• What does the second transaction cost the participants if it happens off-platform, including the risk they take on themselves?
• Which categories have the highest repeat rate between the same two parties? That is where your leak is, and it is measurable from your own data.

The structural fixes make staying on the platform better than leaving: scheduling both sides rely on, payment terms or financing neither could arrange alone, recourse with teeth, records needed for tax or compliance, and steady demand. Policing fixes like masked contact details, penalty clauses, and pattern detection buy time, but they do not change the arithmetic that made leaving attractive.

The precondition table

Some markets support marketplaces and some do not, and it is largely decided before you start.

Condition	Supports a marketplace	Collapses into direct relationships
Frequency between the same two parties	Rare or one-off	Frequent and predictable
Supplier differentiation	High, buyers need to compare	Low, any supplier will do
Discovery difficulty	Hard without a platform	Trivial, or already solved elsewhere
Trust requirement	High stakes, strangers	Low stakes, or existing relationships
Transaction complexity	Payment, scheduling, or recourse are messy	A phone call settles it
Fragmentation	Many small players on both sides	A handful of large ones on either side

Two or three columns in the wrong place is a difficult marketplace. Most of them in the wrong place is a directory that will eventually be asked to justify a fee.

The economics are shaped differently

Marketplaces do not own the cost of what is sold, which makes their contribution margin on paper look unlike a business that does. That is real, and it produces two specific errors.

The first mistake is measuring the wrong top line. Value transacted through the platform is not revenue; only your fee is. That is the distinction between gross flow and captured money drawn in revenue models.

A model built on the larger number justifies spending the smaller cannot support. Keep both, label both, and run all economics on the fee.

The second is underestimating what you own. You do not carry inventory. You carry trust, fraud, disputes, quality failures, and the customer service that follows all three. Those costs scale with transaction count, not revenue. They scale faster in the highest-stakes categories.

A marketplace with a low fee in a high-stakes category can be structurally unprofitable no matter how large it gets.

When to stop being a marketplace

Several honest endings, each with its own signal.

If quality complaints dominate and the platform cannot enforce standards it does not control, the answer is usually a managed marketplace: you set the price, guarantee the outcome, and take responsibility. The fee rises and so does the operational burden.

If suppliers stay but the transactions leave, the answer may be to sell them software instead of a fee per transaction, and let the transactions happen wherever they happen. You trade take rate for a subscription that does not depend on winning every deal.

If supply is unreliable and demand is not, owning inventory or employing the supply removes the variability at the cost of a much heavier balance sheet. This is a different business, and it should be evaluated as one rather than as a phase.

The mistake is treating any of these as a failure. A marketplace is a structure, not an identity, and the structures next to it are frequently better fits for the same market.

Before you build

Four questions, answered in writing, in this order: Which side is constrained, and what evidence says so? What is the narrowest slice where you could be genuinely dense? On the second transaction between the same two parties, what will you do that you did on the first, and which side captures more from a match than the other?

If you cannot answer the third, the rest of the plan does not matter yet.

For the general planning frame around any of this (the sections a lender, partner, or investor will look for), the U.S. Small Business Administration's business plan guide is free and reasonably structured.

Bottom line

Build density before revenue, charge the side that captures the surplus, and be able to name what your fee buys on every transaction rather than just the first. A marketplace that leaks is not being cheated; it is being told, accurately, what it is worth.

Common questions

How narrow should the first slice be?

Narrow enough that you could name the suppliers in it. If you cannot list them, it is still too wide to reach density by hand, and density by hand is how almost every liquid marketplace started.

Is a subsidy on the hard side a bad sign?

Only without an end condition. Write the local density at which the subsidy stops, before it starts. A subsidy with no stopping rule quietly becomes the business model.

What if participants keep transacting off the platform?

Measure it before you police it. Then decide whether to make staying worth more or leaving harder, and be clear that those are different strategies with different consequences.

Can a marketplace charge nothing at first?

Yes, and the risk is that participants price your service at nothing permanently. If you intend to charge later, say so at the start and say roughly when.