In this article 14 sections
A marketplace MVP should prove one complete transaction loop between supply and demand. Start with one side's acquisition problem, constrain geography or category, make matching and trust operationally workable, and only automate the parts needed to complete real transactions reliably.
A marketplace is not a directory#
A directory can show listings. A marketplace has to help two different user groups complete an exchange. That usually introduces onboarding, search or matching, trust, communication, payments or booking, cancellation, support and administrative intervention.
Choose which side is harder first#
Most marketplaces have a constrained side. It might be qualified plumbers, niche equipment sellers, specialist tutors or buyers with a specific budget. Build the launch plan around the side that is harder to acquire or keep active, because demand without supply or supply without demand creates an empty product.
| Layer | V1 requirement | Can often wait |
|---|---|---|
| Supply | Onboarding, availability or listing creation | Advanced seller analytics |
| Demand | Discovery or matching | Deep recommendation systems |
| Trust | Identity, basic reviews or moderation | Complex reputation scoring |
| Transaction | Booking, checkout or lead acceptance | Multi-currency optimisation |
| Operations | Admin view and intervention | Full automation |
Design payments around the business model#
Stripe Connect is built for platforms and marketplaces that move money between multiple parties. Its marketplace model covers connected-account onboarding, payments, application fees and payouts. The exact integration should follow who is merchant of record, how disputes are handled and when sellers should receive funds.
Do not hide operations from the MVP#
Early marketplaces often need manual intervention. That is not a failure. A small admin tool that lets the team approve supply, resolve a failed match, refund a transaction or contact a user can be more valuable than months spent automating edge cases before volume exists.
Constrain the launch#
Geography, category, transaction type and availability windows are useful constraints because they concentrate liquidity. A marketplace that is theoretically available everywhere can feel empty everywhere. A narrow launch can create a stronger experience and better learning density.
Privacy and trust start in V1#
If the marketplace handles identity, addresses, messages, payments or other personal information, privacy cannot be postponed to the scale-up phase. The ICO's current guidance says data protection should be considered at the design stage and throughout the product lifecycle.
Measure completed exchanges#
Track the path from a qualified request to an accepted and completed transaction. Record time to a match, cancellations, reasons for failure and repeat use. Review those measures separately for buyers and suppliers. A growing list of accounts does not show that either side is receiving value.
Prepare a manual operating playbook#
Before the pilot, write down who handles unavailable suppliers, unsuccessful payments, cancellations and complaints. Give the operator enough visibility to identify the transaction and contact the right person. Record interventions so the team can see which problems are rare and which deserve product work.
Start with a cohort the team can support directly, then expand when successful transactions become repeatable. Use the marketplace cost guide to keep software, acquisition and day-to-day operations in separate budgets.
Start with a deliberately small operating zone#
An illustrative tutoring marketplace might begin with one subject, a limited group of tutors and a set of available appointment windows. That makes it possible to know whether a request failed because there was no suitable supply, a provider did not respond, or a customer rejected the offer. A nationwide empty catalogue conceals those distinctions.
Recruit the harder side deliberately, but avoid assuming supply is always the constraint. In some markets providers are easy to list and qualified buyers are scarce. In others a buyer’s need is obvious but reliable availability is difficult. Observe the bottleneck for your specific exchange.
Set an operating rule for unfulfilled requests: how long you try, what the customer hears and whether you offer an alternative. Do not let an unanswered request remain an apparently active order indefinitely.
Keep a small transaction state model#
| State | What is true | Next permitted action |
|---|---|---|
| Requested | The buyer has expressed a specific need | Qualify, match or decline |
| Offered | A suitable provider and terms are proposed | Accept, reject or expire |
| Confirmed | Both sides know the agreed outcome | Fulfil or enter the cancellation process |
| Completed | The service has been delivered under the chosen rule | Record fees and permitted feedback |
| Cancelled or disputed | The normal path has stopped | Assign an owner and record the resolution |
Attach payment status separately where useful. A confirmed booking can have an unresolved payment, and a completed service can later be disputed. Decide which system is authoritative for each fact. Staff should be able to explain the record without inferring state from a sequence of emails.
Measure liquidity with explicit denominators#
Define a qualified request, the response window and what counts as completion. Then report the number that found suitable available supply, the number accepted and the number completed. Separate unqualified requests from failed matching rather than quietly removing inconvenient cases.
In an illustrative pilot, 30 qualified requests might produce 18 suitable offers and 12 completed exchanges. That is a 60% offer rate and a 40% completion rate per qualified request. It is not a claim about what a successful marketplace should achieve. Break the losses down by reason and record operator time before deciding which feature to build next.
For the economics, track fees earned minus payment charges, incentives and variable support costs using the actual model. Keep customer acquisition separate. Our marketplace budget guide separates platform delivery from the work of making an active market.
Put this guide to work#
Frequently asked questions#
Should I build the buyer or seller side first?
Build the operating loop around the harder constraint in your specific market. You may recruit one side manually before opening the other. The first product still needs a way for both parties to complete the exchange and for an operator to handle failure.
What is marketplace liquidity?
For this guide, it means the ability of a qualified request to find suitable, available supply and progress towards completion within a defined window. Specify the segment and denominator when measuring it; total listings alone cannot tell you whether buyers can transact.
Can a spreadsheet run the first marketplace?
A spreadsheet and manual coordination can help test a small operating process when access and data handling are appropriate. Record states and responsibilities consistently. Move work into software when the manual process creates a demonstrated bottleneck or unacceptable failure risk.
How do I stop buyers and sellers going off-platform?
First understand why they do so. Clear terms, useful coordination, support and a valuable transaction experience may matter more than restrictive features. Choose an economic model that reflects the service you actually provide, and get appropriate advice on contractual restrictions.
When should I expand into another city or category?
When you understand the current segment’s completion rates, recurring failure modes and support economics well enough to reproduce the operating model. A larger listing count alone is weak evidence. Expand with a stated hypothesis and a way to compare the new segment.
Sources and methodology#
This guide combines editorial analysis with the linked primary sources. Decision frameworks, worksheets and worked examples are our own; examples are illustrative unless explicitly identified as supplier claims or published research. We have not conducted original interviews, comparative supplier testing or a controlled experiment for this article.
- Stripe: design a marketplace ↗
Primary documentation for marketplace payment architecture. Commercial, tax and legal responsibilities depend on the business and configuration.
Accessed 16 October 2026 - Stripe: choose a charge type ↗
Explains how Connect charge models affect the flow of funds, refunds and disputes.
Accessed 16 October 2026 - GOV.UK: learning about users and their needs ↗
Supports research into existing behaviour; our startup exercises and thresholds are editorial examples.
Accessed 16 October 2026 - ICO: data protection by design and by default ↗
Primary UK guidance on considering data protection during design and operation. The appropriate arrangements depend on the actual service.
Accessed 16 October 2026
Source check: 16 October 2026. Platform documentation can change. Published as part of our editorial collection.
Expanded 16 October 2026 with practical decision material, downloads and topic-specific answers. Supplier and platform claims are identified by their linked sources.
MVP Build Editorial. “How to build a marketplace MVP without building a directory.” MVP Build, 9 September 2026.
https://mvpbuild.xyz/marketplaces/how-to-build-a-marketplace-mvp/