Online marketplace development: how to build a two-sided platform

• Liquidity decides the outcome more than any feature does. Both sides have to be present and transacting at once, so plan how you seed the hard side before you scope the build.
• Move money through a payment facilitator such as Stripe Connect or Adyen. Holding funds yourself can pull you into state money-transmitter licensing and the audits and reporting that come with it.
• Verify the supply side and keep raw card data out of your backend. KYC and KYB through the facilitator, and Stripe-hosted payment fields to keep PCI DSS scope small.
• Buy a packaged platform when off-the-shelf covers the use case; go custom when core transaction rules cannot be supported cleanly. Know what is missing before you commit.

A two-sided marketplace connects buyers with sellers or providers and takes a cut of the transaction. The model changes the build more than most founders expect, so it is worth being precise about which one you are building before anyone writes code.

Product marketplaces move goods and lean on logistics and returns, while service marketplaces sell someone's time and lean on scheduling and proof of completion, which changes when and how money should be released. Fix the model first, because it decides the payment flow and the trust model, which in turn shape the data model underneath everything else.

This is the part that decides whether you have a marketplace at all. A two-sided platform only works when demand reliably finds available supply, and at launch neither side has a reason to be there before the other. Andrew Chen's Cold Start Problem, the framework a16z built around launching networked products, calls the fix an atomic network: the smallest set of users where the thing works, usually built by constraining geography or category and seeding the hard side by hand.

Before I talk features with a founder, I ask a different set of questions.

Before discussing features, we identify the competition and how buyers find sellers today. Even if there is no competing platform, there is an existing way of doing business. The founder needs to explain why both sides would switch: what makes joining worthwhile for sellers, and why would buyers choose the platform over their current options?

Then we'd look at the onboarding plan. How will the first sellers be recruited, and what will keep them active until buyers arrive? Getting someone to register is not enough; they need to be available and ready to respond. For local services, those providers also need to cover the areas where you're attracting customers. Hundreds of sign-ups mean little if buyers still can't find someone available to do the job.

We'd recommend starting with a focused market where buyers can actually find suitable sellers, rather than launching everywhere with too few participants in any one area. The goal is to get transactions happening and give both sides a reason to come back, not simply grow the number of accounts.

Registrations are a vanity metric, because what matters is whether a buyer who arrives can find a seller ready to transact in their category and area on the first visit. That is why launching narrow beats launching wide: a hundred active sellers in one city produce transactions, while a thousand scattered across the country produce an empty search result. The whole build should serve that goal, and if the plan for it is thin, the platform will not save it.

Before building the platform, know why both sides would join and how you'll get the first transactions to happen.

Once two sides are transacting, the next thing that decides your fate is how money flows between them, and the safe default is to let a licensed payment facilitator hold and move the funds while your platform decides the rules. Stripe's Connect and Adyen for Platforms both split a single charge between platform and seller, hold funds until payout, and onboard sellers with identity checks.

Stripe Connect would usually be our first choice. We'd start with three questions: who gets paid, what does the platform keep, and when should sellers get their money? For an order involving a single seller, we'd review destination charges and collect the platform's commission as an application fee. If the payment needs to be split between several sellers, or the seller is chosen later, we'd look at separate charges and transfers.

For a services marketplace, we could trigger a payout when the buyer confirms the job is done. Otherwise, it could happen automatically after a set period for reporting problems. A complaint would pause that automatic payout and send the transaction for review. We'd build those rules around the payment provider.

That maps to a small set of decisions the build has to encode.

The line that ends marketplaces is the temptation to hold the money yourself.

We would strongly advise a startup against collecting sellers' money into its own bank account and paying them out itself. Depending on the setup and where the business operates, that can bring licensing requirements, financial audits, regulatory reporting, and ongoing compliance work. These are obligations that can continue long after the software is finished, not just paperwork to get through before launch.

The development bill is only part of the cost. You also need the legal, financial, and compliance expertise to run it properly. We would see that as a potentially huge ongoing expense, not a clever way to save on payment-provider fees. Building rules that tell Stripe when to pay a seller is one thing; taking responsibility for holding and distributing that money yourself is another. For most startups, we'd consider it a poor use of both money and engineering time.

The reason is regulatory as much as operational, and it pays to understand it before you design the payment flow. FinCEN's rules set narrow conditions under which a payment processor is not a money transmitter, and the current definition sits at 31 CFR 1010.100(ff), building on its 2003 ruling for merchant processors. Hold and distribute other people's money outside those conditions, and you can trigger state money-transmitter licensing across the states where you operate. Facilitators such as Stripe Connect and Adyen exist to absorb exactly that. This is where a marketplace intersects with financial regulation, so treat the payments architecture as much a legal question as an engineering one, and take counsel on structure and state licensing before you build. For the payment mechanics, our guide to payment API integration and our piece on fintech software development go deeper.

Buyers do not come back to a marketplace where sellers are not vetted, so verification is where a platform earns the right to a take rate. The practical approach is to let the facilitator do the identity work rather than build a document-checking system.

For seller verification, we'd use Stripe Connect's onboarding for KYC and KYB, rather than build our own document-checking system. Stripe collects and checks the required identity and business information; our application tracks the account's status and any restrictions on payments or payouts. That doesn't mean a verified seller can be trusted to deliver every order. Identity checks don't replace the marketplace's own fraud monitoring and complaint handling.

Verification confirms who a seller is, but not that they will deliver, which is why the platform still needs its own fraud monitoring and a clear way to act on complaints. Treat KYC and KYB as the floor, not the ceiling, of trust.

Every marketplace has to decide what happens when an order goes wrong, and the answer has to be built into the payout timing rather than handled by email after the money has moved.

For buyer-seller disputes, we'd set clear rules for reporting problems and keep order-related communication on the platform. A complaint raised before the scheduled payout would pause that payout and bring in an administrator to review the order, messages, and supporting evidence. They would then decide whether to refund the buyer or release payment to the seller. We'd give both parties a clear explanation and record the decision. Card chargebacks are a separate process, so we'd also establish who handles them through the payment provider and submits the required evidence.

For card data, we would keep raw card numbers and security codes entirely out of our backend. We'd use Stripe Checkout or Stripe's payment fields so those details go directly to Stripe. That reduces PCI DSS scope, but it doesn't remove the business's remaining compliance responsibilities. Building our own card-storage system would add security risks, costs, and ongoing compliance work that we would strongly advise a startup against taking on.

Keeping card numbers out of your systems is the single biggest lever on compliance cost. PCI DSS v4.0.1 applies to anyone who stores, processes, or transmits cardholder data, and routing card entry straight to Stripe keeps most of your platform out of that scope. Chargebacks run on the card networks' own timeline, so decide up front who gathers evidence and responds, because an unmanaged chargeback rate will get your payment account throttled.

Liquidity is expensive to acquire and easy to waste, so matching demand to the right supply is the core experience of the marketplace, not a feature you add later. If a buyer cannot find the right seller in the first few results, the supply you paid to recruit might as well not exist, which is why filtering, ranking and availability signals deserve real investment rather than a basic keyword search bolted on at the end. On a services marketplace that means surfacing providers who are available and cover the buyer's area, rather than the closest text match.

However you charge, whether by commission, subscription, or listing fees, deduct it at charge time through the facilitator rather than invoicing sellers afterward, because a commission collected as an application fee on the original charge reconciles itself while a fee you try to collect later becomes a collections problem and a fresh source of disputes. Decide the take rate model early, because it shapes the payment flow and the unit economics that determine whether the marketplace can fund its own growth.

A packaged platform such as Sharetribe or CS-Cart can get a marketplace to market fast, and the real question is whether it fits your transaction well enough to stay or becomes the thing you rip out a year in.

The decision depends on how well existing solutions cover the use case, the client's resources, and where the product is heading. We would not treat a marketplace as a small development project simply because the concept is familiar. The scope includes everything around the transaction, not just listings and checkout.

Our first question would be: "Which existing solutions have you researched, and what aren't they doing right for your use case?" If that cannot be answered confidently, the justification for custom development may not exist yet. Trying a packaged platform can help establish what is genuinely missing.

A custom build is worth considering when the available options cannot cleanly support essential business rules, integrations, or transaction workflows. Even then, the decision does not have to be all-or-nothing: an existing platform with a targeted custom integration may be enough.

The honest test is whether you can name what off-the-shelf is missing and why it matters to your business. If you cannot, a packaged platform is the cheaper way to find out, and a custom build is premature.

Before you commit to a custom build, know what's missing from the off-the-shelf options, and why it matters for your business.

For a custom build, our notes on web application development and how to staff it with a dedicated software team over the delivery side, and the parent guide to ecommerce development services.

Because the hard parts are payments, liquidity and trust rather than screens, the right partner is the one who talks about those first, and the warning signs are the opposite.

The ways a marketplace build goes wrong are consistent enough to name in advance:

• A platform launches wide and sits empty because neither side reached liquidity in any one market.
• The founder holds funds to save on fees and inherits money-transmitter obligations across multiple states.
• Sellers are onboarded without verification; fraud arises, and buyers stop coming back.
• Commission is bolted on after the charge, so reconciliation and disputes eat the take rate.
• The build hard-codes exactly two sides, and adding a third side later means a rebuild.

Everything traces back to treating the marketplace as a feature project rather than a liquidity and money-movement problem.

How much does it cost to build an online marketplace?

It depends on whether you start with a packaged platform or build custom, and on how much of the transaction is standard. Rather than a self-published range, scope it against your real requirements; our guide to software development pricing explains what drives the number.

Should I use a no-code platform like Sharetribe or build custom?

Use a packaged platform when it covers your use case, and you are still proving demand. Build custom when core transaction rules or integrations cannot be supported cleanly, and only once you can name what off-the-shelf is missing and why it matters.

How do marketplace payments work without becoming a money transmitter?

Route funds through a licensed facilitator such as Stripe Connect or Adyen, which holds and moves the money while your platform sets the rules. Holding and distributing funds yourself can trigger state money-transmitter licensing requirements, so seek counsel on structure before you build.

What is the hardest part of building a marketplace?

Liquidity is the hardest part, because both sides have to be present and transacting at once. Solving that cold-start problem by launching narrowly and seeding the supply side by hand is harder and more decisive for the outcome than any feature you could add to the platform.

How do you verify sellers on a marketplace?

Use the payment facilitator's KYC and KYB onboarding to verify identities and business details, and track each seller's status within your application. Verification is the floor; the platform still needs its own fraud monitoring and complaint handling.

• Euromonitor International, "Digital Disruptors: the global online marketplace landscape in 2025." Marketplace share of global retail ecommerce (62% in 2024, about $2.4 trillion) and third-party sales (72% in 2014 to 81% in 2024). https://www.euromonitor.com/article/digital-disruptors-the-global-online-marketplace-landscape-in-2025
• Amazon, "2025 Small Business Empowerment Report." Independent sellers account for more than 60% of sales in Amazon's store. https://www.aboutamazon.com/news/small-business/amazon-2025-small-business-empowerment-report
• Digital Commerce 360, "Top Online Marketplaces Data and Stats." Top 100 global marketplaces GMV (about $3.83 trillion, April 2024, used as dated secondary context). https://www.digitalcommerce360.com/top-online-marketplaces-data-stats/
• Stripe, "Connect documentation." Split charges (destination charges, separate charges, and transfers), holding funds, payouts, and KYC/KYB seller onboarding. https://docs.stripe.com/connect
• Adyen, "Adyen for Platforms documentation." Split payments, funds held in balance accounts until payout, and seller verification. https://docs.adyen.com/platforms/
• FinCEN, "Definition of Money Transmitter (merchant payment processor)," FIN-2003-8, and the current definition at 31 CFR 1010.100(ff). Conditions under which a processor is not a money transmitter. https://www.fincen.gov/resources/statutes-regulations/administrative-rulings/definition-money-transmitter-merchant-payment
• PCI Security Standards Council, "PCI DSS v4.0.1." Applies to any entity that stores, processes, or transmits cardholder data. https://www.pcisecuritystandards.org/standards/pci-dss/
• Andrew Chen and Andreessen Horowitz, "The Cold Start Problem." Framework for launching networked products (atomic networks, the hard side, the tipping point). https://a16z.com/books/the-cold-start-problem/