Marketplace MVP: which side to build first, and what to leave out

A marketplace looks like one product: listings on one side, buyers on the other, a transaction in the middle. Building one teaches you that it is three products. The buyer’s, the seller’s, and the operations tooling that keeps the two honest. Trying to build all three at full size in a first version is how marketplace projects run out of money before the first transaction.

Here is how we scope a marketplace first version, from having built them for B2B sourcing and for consumers.

Decide which side is harder to get

A marketplace with nothing to buy has no buyers. A marketplace with no buyers loses its sellers. One of the two sides is harder to acquire, and it is almost always supply: the vendors, the tutors, the suppliers, the people with something to offer.

The first version should be built around getting that side on and keeping it. Often that means the first product is really a single-side tool: a way for suppliers to list, manage and receive orders, with buying handled simply, even manually, until there is enough on the platform to buy. That is not a compromise. It is the marketplace finding its feet in the right order.

Scope the first transaction, end to end

Pick one category, one kind of transaction, and walk it all the way through: listing, discovery, order, payment, fulfilment, confirmation, and what happens when it goes wrong. That single path, working reliably for real people, is the first version. Every feature that does not sit on that path waits.

For a B2B sourcing marketplace, the first transaction might be a buyer requesting a quote and a supplier answering it, with payment off-platform at first. For a consumer marketplace, it might be one product type in one city with one delivery partner. Small on purpose.

Build the operations tooling from day one

This is the part first versions skip and regret. Disputes, refunds, a seller who does not ship, a listing that breaks the rules, a payout that fails. Every one needs a screen your team can act from. Without it, your operations team runs the marketplace from a spreadsheet and a WhatsApp group, and the platform is only as reliable as their evenings.

The admin does not have to be pretty. It has to exist, and it has to let a person fix things by hand quickly. We build it as a first-class product, because your team lives in it.

Payments: get the shape right early

Split payments and seller payouts, invoices and statements, tax handling that matches how you actually operate. These are hard to retrofit. Even if the first version takes payment off-platform, design the flow so that moving it on-platform later does not mean rebuilding orders.

What waits for version two

Ratings and reviews, until there are enough transactions for them to mean anything. Promotions and discounts. Recommendations. Subscriptions. Multiple categories. A native app, unless the users genuinely live on their phones from day one. Each of these is valuable, and each of them is worth more when it is built on real transaction data rather than guesses.

The metric that matters

Not sign-ups. Completed transactions, and the share of them that needed a person to intervene. When that share drops below what your operations team can handle comfortably, the marketplace is ready to grow. Until then, growth just multiplies the manual work.

A realistic first version

One category. Supply-side tooling that suppliers would use even if no buyer existed yet. A single transaction path that works end to end. An admin that lets your team fix anything by hand. Payments designed for the future even if handled simply now. Everything else on a list, in the order users vote for it.

That is a marketplace a small team can ship in a few months and learn from immediately. If you are planning one, we would like to hear about it, including which side you think is harder to get.