How to build a two-sided marketplace

To build a two-sided marketplace, you solve three problems that an ordinary application never faces: attracting two audiences that only show up once the other is already there, moving money between third parties inside a regulated framework, and keeping trust when strangers do business with each other. The code comes after that. This guide follows the same order: the model, a manual launch, payments, trust, and only then automation.

Whether you are connecting businesses with specialist contractors, consumers with local service providers, or buyers with independent sellers, the mechanics are the same: supply, demand, and a transaction you make easier.

Step 1: define the transaction, not the screens

Before listing features, write one sentence that says what is exchanged, between whom, and at what moment the platform is useful. Three questions settle most of the technical choices that follow.

A marketplace that matches a homeowner with an emergency plumber is not built like one that matches a company with a trainer for a three-month programme. The first lives on speed and availability. The second lives on quotes, trust and follow-up.

Your revenue model comes out of that sentence. A commission on every transaction means the money flows through you, so you need integrated payments. A subscription on the supply side (providers pay to be listed) or paid introductions (buyers pay for contacts) only need ordinary payments, with no payouts to third parties. This is the decision with the biggest effect on budget, and it is made before anyone draws a screen.

Step 2: solve the chicken-and-egg problem

No buyer stays on an empty marketplace, and no provider signs up where there are no buyers. This cold start kills more marketplaces than any bug. You do not solve it with code but with a narrow scope and manual work.

• Start with the scarcer side. It is almost always supply: good providers who are available and willing to try a new channel. Recruit them one by one, by phone or in person, and fill in their profiles for them if needed.
• Shrink the playing field. One city, one category, one type of job. A dense marketplace in a small niche beats a thin national directory: buyers find someone, providers get requests.
• Give one side value before the network exists. A tool that helps a provider on their own (calendar, quotes, client records) attracts them before demand arrives. Matching then becomes a bonus rather than the only promise.
• Bring the first demand yourself. Partnerships, outbound sales, content: early transactions are usually engineered, not organic. That is fine as long as you measure whether buyers come back.

Step 3: launch "manual first"

The temptation is to build the matching algorithm, real-time chat, mobile apps and seller dashboard on day one. It is the most reliable way to spend the budget before the first transaction. A marketplace MVP tests one thing: do transactions happen, and do they repeat?

The "manual first" rule: anything the team can do by hand during the first weeks is done by hand, and software only automates what becomes painful at real volume.

What is never done by hand: account security, personal data protection (see our GDPR checklist) and, if money flows through you, the payment setup described in the next step.

Step 4: move money the right way

As soon as the platform collects a buyer's money in order to pass it on to a provider, it enters regulated territory. In the European Union, the second Payment Services Directive (PSD2) only leaves a platform outside its scope if it acts as a commercial agent for the seller alone, not for the buyer as well. The European Banking Authority confirmed this in a published answer from December 2021, adding that each national regulator assesses the business model case by case. Other jurisdictions have their own payment licensing rules. In short: do not improvise a single bank account that receives everything and pays out by hand. Have a lawyer review the money flow.

The usual route is a licensed payment provider designed for platforms. With Stripe Connect, for example, each provider gets a connected account: the buyer's payment is split between the provider's share and the platform's fee, and the payment provider handles seller identity verification. Stripe documents what each connected account must supply depending on country and activity; while information is missing, payments or payouts can be paused.

That choice drives design decisions you should make early:

• Who pays processing fees, the platform or the provider, which decides the Connect pricing model. Fees are detailed in what it costs to build a marketplace.
• When providers get paid: at booking, after delivery, or after a claims window. Delayed payouts protect buyers but tie up providers' cash.
• How refunds and disputes work: who refunds, from which share (including your fee or not), and who absorbs a chargeback.
• Who invoices what: the platform invoices its fee; the service itself is invoiced by the provider, or by the platform on their behalf if a self-billing agreement allows it. Check local invoicing rules, which are tightening in several countries.

Step 5: build trust and moderation

On a marketplace, two strangers trust each other because you guarantee the framework. That framework has four parts.

1. Profile vetting. Identity, business status, insurance or qualifications depending on the trade. The payment provider handles financial identity checks (KYC), but checking that a provider is fit for the job remains your responsibility.
2. Reviews. Only after a real transaction, with a right of reply, and a clear public explanation of how reviews are checked. Consumer protection authorities in many countries pursue fake or filtered reviews.
3. Moderation. Written rules, a report button, a queue in the admin panel and a record of every decision. If you serve EU users, the Digital Services Act requires marketplaces to verify and display the contact details of professional sellers, with lighter requirements for micro and small companies.
4. Disputes. A simple procedure known in advance, and a period during which the money has not yet been paid out.

Tax reporting completes the picture. Under the EU's DAC7 rules, platform operators report the income earned by their sellers and providers every year, for activity from 1 January 2023 onwards (see the French tax authority's guidance for one national implementation). Collect the required data at sign-up rather than chasing every provider at reporting time.

Step 6: choose the technology last

Technology is the last decision, and the most reversible one. There are three options, each with its own sweet spot.

• Off-the-shelf marketplace software. Several vendors offer configurable marketplace platforms. They are a good way to test demand with a standard model: listings, booking, commission.
• No-code tools. Fast for a demo, they show their limits on payment rules, access rights and growth.
• Custom development. It pays off when your transaction does not fit a standard model: quote before payment, multi-stage jobs, commission rules by category, integration with your existing tools, or a platform that is itself the product you sell.

Architecturally, a two-sided marketplace is a SaaS platform with two kinds of customers: separate accounts and roles, an admin back office, payments, notifications and audit logs. A responsive web application is almost always enough to start; a mobile app comes when one side genuinely works on the move.

If your project is really about booking a single provider (your practice, your rooms, your equipment), it is not a marketplace: see building a custom booking platform, which is much simpler.

Step 7: measure what matters

A marketplace runs on a handful of metrics, as long as they are the right ones:

• Fill rate: the share of buyer requests that end in a transaction. Low fill rate means you are short of supply.
• Active provider rate: the share of providers who completed at least one transaction in the period. If it is low, you are short of demand.
• Repeat rate: buyers and providers who transact again. This is what tells you the platform has value beyond the first introduction.
• Time to match: the delay between a request and a provider's response.

These four numbers tell you where to put the effort: recruiting supply, finding demand, or improving the product. You can track them from the manual version onwards, in a spreadsheet if necessary.

Where to start

Before pricing anything, the most useful step is to see the journey on both sides: the buyer's request, the provider's response, the payment, and the back office that oversees it all. That is what a visual prototype shows. LPR Studio builds one for free and presents it in a video call within 5 working days; it then becomes the basis for a fixed price or a subscription with no upfront build cost. The prototype also helps decide what stays manual at launch, which is often where the budget is won or lost.