How to Build a Two-Sided Marketplace: A Founder's Guide
How to build a two-sided marketplace: solve the chicken-and-egg problem, set a take rate, design payments with Stripe Connect and keep the MVP small.

Freelance full-stack developer
- Published
- Reading time
- 13 min
In this post9
To build a two-sided marketplace that works, you have to solve three problems that have little to do with code: getting buyers and sellers to show up at the same time, moving money safely from buyer to seller with your cut taken out, and giving strangers a reason to trust each other. My advice is to build the smallest version that can complete one real transaction end to end, and leave everything else for later.
I'm a freelance developer in Denmark who builds web platforms, so I have a stake in this topic. That's why there's also a section on when not to hire someone like me.
The short answer: three phases, one rule
Build a marketplace in three phases, where each phase has to prove the next one is worth paying for.
| 1. Manual test | 2. Template or no-code | 3. Custom-built MVP | |
|---|---|---|---|
| Goal | Prove both sides show up and transact | Repeat transactions without you in the middle | Build what makes your marketplace different |
| Tools | A form, a spreadsheet, payment links and your phone | A marketplace template such as Sharetribe, or a no-code tool such as Bubble | A custom web app with a multi-party payment service such as Stripe Connect |
| Time to launch | Days | Weeks | Typically 2-4 months for a lean version |
| Move on when | You have become the bottleneck | The tool limits your model or takes too much of your commission | Data from real transactions tells you what to build next |
The rule: only move to the next phase when the current one is holding you back. Skip the manual phase only if you already have both sides, for example because you already broker deals by hand.
Not sure a marketplace is the right kind of platform for your idea? My guide on how to build your own platform compares off-the-shelf tools, no-code and custom builds. The rest of this post assumes you've settled on a marketplace.
Step 1: Solve the chicken-and-egg problem before you write code
Buyers won't come to a marketplace with no sellers, and sellers leave a marketplace with no buyers. That's the chicken-and-egg problem, and no amount of engineering fixes it. Focus and unglamorous manual work do.
What I usually recommend:
- Go narrow on niche and geography. A marketplace for wedding photographers in Copenhagen can have enough supply for couples to find someone. A marketplace for every kind of photographer across Europe will feel empty for months.
- Start with the side that's harder to get. That's usually supply: the sellers, hosts or service providers. Call them, meet them, and create their profiles for them if that's what it takes.
- Give one side a reason to stay on its own. If sellers can use your platform to send quotes, manage a calendar or get paid, they'll stick around before buyers arrive. This is often called single-player mode.
- Match people by hand. Broker the first deals yourself over email and phone. It's slow, but you learn what buyers ask about and why deals fall through.
- Measure liquidity, not sign-ups. The number that matters is the share of buyer requests that turn into a completed transaction, and how long that takes. Twenty busy sellers tell you more than 500 empty profiles.
Only when transactions repeat and you've become the bottleneck is it time to automate. Until then, every euro spent on development is a euro not spent on recruiting supply.
Step 2: Pick a take rate that survives payment fees
Your take rate is the share of each transaction the platform keeps, paid by sellers as a commission, by buyers as a service fee, or split. There's no correct number. It depends on how much the platform does beyond the introduction: payment protection, invoicing, scheduling or customers the seller would never have found alone.
What founders tend to miss is how much of that commission goes to payment fees. Here's a worked example using Stripe's published Connect pricing for Ireland, with the platform setting seller fees itself and taking 12%.
| €100 order | €20 order | |
|---|---|---|
| Commission | €12.00 | €2.40 |
| Card fee for a standard EEA card (1.5% + €0.25) | €1.75 | €0.55 |
| Payout to the seller (0.25% + €0.10) | €0.32 | €0.14 |
| Active seller account (€2 per month) | €2.00 | €2.00 |
| Left for the platform | €7.93 | minus €0.29 |
The example assumes one sale that month, paid out on its own. Fixed fees hit small orders hard. You can fix it by batching payouts weekly or monthly, setting a minimum order value, or letting Stripe handle pricing for your sellers. Then sellers pay the processing fees and you skip the per-account and per-payout fees, but you lose control over what sellers pay. Rates vary by country, so rerun the numbers for your market.
When buyers and sellers go around you
The biggest threat to your take rate is disintermediation, sometimes called platform leakage: buyer and seller meet on your platform, then do the next deal directly. It's most common with repeat services like tutoring, cleaning or a regular freelance designer.
Hiding contact details only helps a little. What works is making it easier to stay: payment and receipts are automatic, reviews only count for transactions on the platform, and the buyer gets their money back if something goes wrong. If the relationship is ongoing from the first job, consider charging sellers a subscription instead of a commission.
Step 3: Design the payment flow
Payments are the technical core of a marketplace: money goes from buyer to platform to seller, and along the way you take your commission, pay fees and handle refunds. I strongly recommend a payment provider built for multiple parties, such as Stripe Connect, Adyen for Platforms or Mangopay, instead of collecting money in your own account and forwarding it. Under EU payment services rules, a platform that collects money on behalf of sellers may need a license unless an exemption applies, so have a lawyer check your model before launch.
A typical transaction looks like this:
- The buyer pays the full amount through the platform.
- The payment provider takes its fee, and the platform keeps its commission.
- The rest sits in the seller's balance with the payment provider.
- Once the service is delivered, or the window for complaints has closed, the money is paid out to the seller's bank account.
Choosing a Stripe Connect charge type
Stripe documents three charge types in Connect. Your choice decides whose name the buyer sees on the payment and who is on the hook for refunds and chargebacks (when a cardholder reverses a payment through their bank).
- Direct charges: the buyer pays the seller's account directly, and the platform collects an application fee. This fits when your platform is mostly a tool for the seller.
- Destination charges: the buyer pays the platform, and a share is transferred straight to the seller. This suits most marketplaces with one seller per transaction. Refunds and chargebacks come out of the platform's balance, and you can reverse the transfer to recover the money.
- Separate charges and transfers: the payment and the transfer are decoupled. You need this when one cart holds items from several sellers, or when the seller is only assigned after the buyer has paid. It's also the most complex option to build.
If you want to hold money until a job is done, you can switch sellers to manual payouts. Stripe's documentation on manual payouts is clear that it doesn't offer escrow in the legal sense, and that businesses in most countries outside the US must be paid out within 90 days. That works for a renovation job, but not for an event venue booked and paid eight months ahead.
Settle the rules before anyone writes code. When can a buyer cancel? Who pays the fee on a refund? What if the seller doesn't show up? Every answer becomes code, and every open question becomes an expensive change mid-project.
Step 4: Build trust in from the first transaction
The buyer needs to believe a stranger will deliver, and the seller needs to believe the money will arrive. At launch you don't have hundreds of reviews to lean on, so trust has to come from elsewhere.
- Vet sellers yourself. A short call, a check of their company registration and a reference or two is enough early on, and it signals quality to buyers.
- Let the payment provider handle identity checks. With Stripe Connect, Stripe verifies sellers' identities and bank details, so you don't store passport scans yourself.
- Keep payment on the platform. Buyers find it easier to say yes to an unknown seller when they know the money is only released once the job is done.
- Write your terms down. Cancellations, refunds, complaints and what the platform is liable for should be clear before the first transaction. Have a lawyer review them.
- Make profiles concrete. Photos, prices, response times and past work say more than a long bio.
- Only let buyers who paid leave reviews. Every review is then tied to a real transaction, which makes fake reviews much harder to plant.
Reviews only matter once there are enough transactions to review. Until then, your own quality control does more for trust.
Step 5: Cut the MVP down to one transaction
Your marketplace MVP (minimum viable product) has to complete one transaction from start to finish without you stepping in: a seller signs up and lists, a buyer finds the listing and pays, the seller delivers, and the money is paid out. Anything that isn't part of that chain can wait.
| In the MVP | Later | |
|---|---|---|
| Matching | Buyers search and filter, or you match by hand | Automated matching and recommendations |
| Messaging | An email at every change in order status | Real-time chat |
| Payments | Card payments, one fixed commission | Multi-seller carts, seller subscriptions, extra payment methods |
| Markets | One country and one currency | Several countries, currencies and languages |
| Trust | Hand-picked sellers and clear terms | Reviews, verification badges and automated fraud checks |
| Disputes | You handle them by email and in the admin panel | A self-service dispute flow |
| Admin | Approve sellers, edit listings, issue refunds, export data | Dashboards and roles for support staff |
| Apps | A web app that works well on mobile | Native iOS and Android apps |
Nothing in the MVP column is optional. Status emails and an admin panel get cut from budgets because buyers never see them, but without them you'll be fixing failed transactions by hand in the database.
Build in seller reporting from day one too. If your platform facilitates the sale of goods, personal services, or the rental of property or vehicles, the EU's DAC7 rules generally require you to collect seller details and report them every year by 31 January. According to the European Commission's DAC7 overview, that also applies to platforms outside the EU with EU sellers. Collect the data during seller onboarding.
For hours and euros per module, I've done the math in my breakdown of marketplace development cost.
Step 6: Choose how to build it
Once transactions repeat, you have three ways to build a proper first version:
- A marketplace template such as Sharetribe. It's the fastest route, and payments with commission are built in. It fits when your model looks like a typical rental, services or product marketplace.
- No-code, for example Bubble. You get more freedom than with a template, but the logic gets hard to follow as your rules grow. I've written about where no-code app builders hit their limits.
- A custom web app. It's the right call when the way you match, price or handle transactions sets you apart, or when the marketplace must connect to systems you already run.
If you go custom, my default is Laravel for the backend, admin panel and payment logic, React or Next.js where the interface needs it, and Stripe Connect for payments. Ownership matters more than the stack, though: the payment account, hosting and code should be in your company's name from day one.
If your idea is really about booking time slots with providers, read my comparison of a custom booking system vs an off-the-shelf tool first. And if several vendors sell physical products, a multi-vendor webshop might be enough, which puts you in Shopify vs WooCommerce vs custom territory.
When not to hire a developer like me
- You haven't had any transactions yet. A manual version or a template is a cheaper way to learn.
- You need native apps and a team working in parallel within months. That calls for an agency or an in-house team.
- The marketplace is your whole company and you're non-technical. Long term, a technical co-founder may serve you better than any contractor, me included.
- Your budget doesn't stretch to a lean first version. A template beats a half-finished custom platform.
Next steps
Run through this list before you commission a custom build. If you can't tick most of it, you're still in phase 1 or 2, and that's fine.
Ready to build your marketplace?
- Core flow: you can say in one sentence who sells what to whom, and how they pay.
- First side: you know which side you'll recruit first and have spoken to real sellers.
- Transactions: you've completed real transactions by hand or on a template.
- Take rate: your commission covers the fees on your smallest typical order.
- Money rules: you've decided when money is released and who absorbs refunds and chargebacks.
- Terms: cancellation, refund and complaint rules are written down.
- Scope: the MVP fits on one page.
- Ownership: the payment account, hosting and code will be in your name.
If you can tick the list, have your plan challenged by the person who'll build it. I start larger platforms with a paid, fixed-price discovery phase where you and I pin down the payment flow, the rules and the MVP scope. You deal directly with the developer writing the code, and you own that code from day one. Here's how I work on custom web apps and platforms.
Frequently asked questions
How long does it take to build a marketplace MVP?
A lean marketplace MVP typically takes 2-4 months with one experienced developer once the scope is settled. Add a discovery phase of a few weeks before that, and ideally a stretch of manual transactions first. What delays projects most often isn't the code. It's decisions about commission, refunds and terms that only get made halfway through.
Should the buyer or the seller pay the commission?
Charge the side that gains the most from the platform and is least sensitive to price. That's usually the seller, because you bring them customers they wouldn't otherwise get. A buyer service fee works when the platform also gives buyers something tangible, such as payment protection. Keep it simple at launch, and test changes on new sellers first.
Can I launch my marketplace in several EU countries at once?
You can, but I'd launch in one country first. Liquidity is local, so two half-empty markets are worse than one busy one. Every extra country also adds VAT questions, local payment methods such as iDEAL in the Netherlands, another language and more support. Build the data model so countries and currencies can be added, and expand once the first market works. Check VAT on your commission with a tax advisor.
How do I handle disputes between buyers and sellers early on?
By hand, using rules you wrote down in advance. Hold the payout until the job is approved, ask both sides for evidence such as photos or messages, and decide based on your terms. You can issue the refund from your admin panel. A self-service dispute flow only pays for itself once disputes take up a regular part of your week.