How Do You Develop a Marketplace? A Practical Guide
How to develop a marketplace: supply, payments, vendor onboarding, search, disputes and the mistakes that catch teams after launch.
How do you develop a marketplace? A practical sequence is to recruit your first sellers by hand, map the transaction loop end to end, decide payments and connected onboarding before you touch UI, cut a lean MVP down to listing, discovery and checkout, then protect trust with verification, disputes and moderation before you spend hard on demand. Adapt the sequence to the marketplace’s fulfilment, regulation and revenue model.
We’ve built 50+ marketplaces over 15+ years, including Costhetix, Sponsorfy and Jollee. After that many builds, this supply-first sequence has worked well in many of the builds we’ve seen, surviving contact with real vendors and real money. Skip a step and you find out the hard way: an empty grid that’s very hard to fix with marketing alone, a payment model that has to be rebuilt once sellers already depend on it, or a roadmap that’s really just workarounds for a foundation nobody chose on purpose.
Start with supply, not software
Before anyone opens Figma, answer: who lists on day one, why they bother, and what “good enough” inventory looks like. Buyer-demand marketing alone rarely fixes an empty grid.
Operator checks we run before we write a line of product code:
- Can you manually recruit the first cohort without the product?
- What does a quality listing require (photos, compliance, pricing rules)?
- What takes a vendor from curious to live with acceptable effort?
- What category boundaries stop the catalogue turning to junk?
- Who owns support when a seller’s first payout is late or wrong?
If you cannot recruit a credible first cohort manually, validate supply before funding the build. The product should remove friction from a motion that already works by hand - not invent demand by launching a pretty shell.
Vendor onboarding is supply work wearing a product face. Forms, verification, draft states, listing quality rules and admin review decide whether inventory ever shows up. Dumping a spreadsheet into an admin panel and hoping sellers self-serve is not a cold-start plan. We treat the first-hour vendor path as part of the commercial model, not a polish ticket after launch.
Niche focus helps - more on that in niche marketplaces. Breadth feels ambitious; depth creates liquidity. A tight geography or a tight category with dense inventory beats a national empty shell in the builds we’ve run comparing both.
Plan the transaction loop before you touch the screens
A marketplace is a commercial loop with a UI attached. Write the loop in plain English before you draw wireframes:
- Seller creates a draft listing
- Listing passes quality or compliance gates
- Buyer discovers the listing
- Buyer commits (pay now, request quote, book slot - pick one primary path)
- If the model is transactional, the platform records and takes its agreed fee
- Fulfilment happens (service, delivery, digital handoff, venue access)
- Payout reaches the seller on a known schedule
- Disputes, refunds and chargebacks have an owner
If a material step remains unresolved, the MVP scope is not ready to fund - you have a wish. Across builds we have shipped, the loops differ (aesthetic appointments, vehicle hire, sponsorship packages, funeral-adjacent services, pub match days) but the discipline does not: one primary path to a trusted transaction, then improve from there.
That planning step also kills vanity sides. Brokers, sub-accounts, white-label partners and internal approvers each multiply permissions, notifications and admin. Add them when the operating model and evidence justify the extra complexity. Launching five-sided on day one is how teams burn the budget before a single seller is live.
Decide payments and connected onboarding early
Marketplace payments are not “add Stripe”. Connected accounts, take rates, payout timing, refunds and dispute ownership shape onboarding screens and admin. Decide the Connect model early, before vendors exist. We keep a dedicated note on Stripe Connect for marketplaces.
Destination charges vs direct charges
In operator language: who is contractually the merchant of record, how is the charge configured, and how does the platform take its fee?
With direct charges, the customer pays the connected account and the charge is created there. With destination charges, the charge is created on the platform and funds are transferred to the connected account, with an application fee for the platform. Charge configuration affects fees, refunds, chargebacks and statement presentation; confirm merchant-of-record and liability separately for the chosen account configuration. This matches Stripe’s current Connect model.
Neither is “more advanced”. A poor fit relative to your trust model can force changes to onboarding, emails and admin after supply already exists. Decide the charge type alongside the take-rate, not as a weekend plugin decision.
Payout timing is product, not finance trivia
Sellers care about when money arrives more than about your homepage animation. Decide and publish:
- When a charge becomes eligible for payout (after fulfilment? after a hold window? immediately on capture?)
- Rolling payout schedule vs manual release for new sellers
- What happens on partial refunds mid-schedule
- How failed bank details surface in seller admin before the seller panics in your inbox
We run delayed eligibility on categories with high dispute risk and faster schedules where fulfilment is crisp and chargebacks are rare. The software must expose the state machine; support must be able to explain it in one sentence. Opaque “processing” without a date can damage supply-side trust after the first good week.
"I have worked with Code23 and their team for over 5 years across 3 different projects ranging from mobile app development to custom WordPress websites… I highly recommend their services to anyone looking for a custom project to be completed on time and in budget."
Webhooks are the nervous system
Do not treat browser success as authoritative; process signed webhooks idempotently and reconcile them against Stripe’s API and stored state. At minimum you need reliable handling for:
- Account updated / requirements due (sellers stuck in verification limbo)
- Payment intent succeeded / failed / cancelled
- Charge refunded and refund updated
- Dispute created / funds withdrawn / funds reinstated
- Payout paid / payout failed
- Capability changes that quietly disable charges or transfers
Idempotent handlers, signed secret verification, replay-safe storage of event IDs, and an admin view of “last webhook received / last processing error” are not optional polish. They are how you notice a broken Connect wiring on a Tuesday instead of when a seller screenshots their bank app on a Saturday. On marketplace builds we ship, webhook monitoring sits next to uptime checks for that reason.
How a connected account is configured (Stripe’s current Accounts v2 API and controller properties, or one of the legacy Express, Standard or Custom account types if you’re already on them) is not a checkbox either. It changes what vendors see, what you hold, and what admin must expose. Get it wrong and you rewrite onboarding after you already have supply.
Cut a lean MVP down to listing, discovery and checkout
Once supply is plausible and payments are blueprinted, cut the MVP to the transaction loop:
- Accounts and roles for both sides
- Listing create / edit / publish with draft states
- Discovery good enough to find a listing
- The path to a paid or committed transaction
- Admin to moderate, pause, edit and see payout/dispute state
Everything else - wishlists, complex gamification, five notification channels, premature native apps - waits. We work through supply, payments, build, testing and launch in that order, so commercial truth lands before UI expands. Senior developers direct AI agents through compressible implementation work; scope, evidence and the agreed fixed quote determine price, while testing stays paranoid about money and trust.
Early scoping is where we kill vanity features. Locking down price, architecture and the payment model happens before anyone burns weeks on screens that don’t close a loop. The build itself ships the loop. Testing stress-tests refunds, disputes and permission edges. Going live means monitoring from day one, not a press release. What comes after is where real liquidity data tells you what to add next.
Cost detail lives in the pillar: how much it costs to build an online marketplace. Platform choice (Sharetribe vs custom) is covered in Sharetribe vs custom.
Search architecture that survives volume
Clone scripts demo search; real marketplaces operate search. In our experience the durable pattern is:
- Structured attributes on the listing - category, geo, price bounds, availability windows, compliance flags - stored as first-class fields, not buried in free text
- Faceted filters that cannot lie - empty result sets must explain which filter killed the match; facets should reflect actual inventory, not a static checklist
- Ranking policy as admin-owned config - freshness, completeness score, fulfilment reliability, manual boosts for curated supply; not a mysterious black box
- Synonyms and category aliases - buyers search the language they know; sellers list in the language they use; without a bridge, liquidity dies in the gap
- Geo and availability as equal citizens - a van with the wrong dates, a practitioner outside the catchment, a sponsorship package you cannot filter by sport: those are product failures dressed as “search bugs”
At small volume, Postgres filters and careful indexes can be enough. As catalogue and query complexity grow, many of our builds introduce a search document projection (often Elasticsearch or OpenSearch-shaped) updated from listing lifecycle events. The projection is derived data: the listing record remains the source of truth; search lag is monitored; reindex is a rehearsed ops path, not a heroics weekend.
Ranking that rewards quality listings is admin policy plus engineering. Skip the policy and you train sellers to game whatever accidental default you shipped.
Protect trust: verification tiers, disputes and moderation
Pretty listing cards do not compensate for “where is my money?”. Sellers may tolerate a plain interface, while opaque payouts can quickly damage trust, as can a take rate they did not understand at signup. Trust UI matters as much as rails: verification states, clear fee copy, visible order status.
Seller verification tiers
Use a risk- and obligation-based ladder where appropriate; exact gates depend on the provider, jurisdiction, activity and category:
- Tier 0 - draft seller: can edit drafts, cannot publish or receive payouts
- Tier 1 - initial checks: profile complete; publishing permissions only where legal, provider and risk requirements allow, with manual review
- Tier 2 - payout ready: Connect onboarding complete, bank details valid, charges and transfers enabled
- Tier 3 - trusted: sustained clean fulfilment, lower review friction, possibly faster payout eligibility
KYC, KYB and other verification requirements depend on the account configuration, jurisdiction, business and regulated activity; design the ladder around those obligations - do not surprise a seller with a dead-end requirements wall after they invested in photography. Surface “what’s blocking you” in seller admin with deep links into the Connect-hosted or embedded onboarding flow. Admin must be able to see requirement errors without asking engineering to dig in Stripe’s dashboard.
Dispute and moderation tooling
Refund and chargeback ownership has to be written down before the first disputed order. Who initiates? Who eats the fee? What does the buyer see while it is open? Those answers change admin screens and email copy. Leaving them until production is how you ship a liability dressed as a launch.
Build admin for the jobs ops actually do:
- Pause a listing or a seller without deleting history
- Freeze payouts pending investigation
- Open an internal case linked to order, payment intent and Connect account IDs
- Record evidence notes and buyer/seller messages in one thread ops can hand over
- Apply category or keyword moderation queues for new listings
- Audit who changed take rate, verification tier or payout eligibility
Moderation gaps trash quality faster than slow marketing can refill the grid. Content rules (photos, prohibited items, claim language) need draft rejection reasons sellers can act on. Silent “pending” with no feedback is how good sellers churn.
We also instrument support load early: payout questions and failed verifications dominate early inboxes on most marketplaces we ship. Software does not answer Slack at 9pm; people do, or a support tier does. Client retainers on our side start at £495/month when they want a named team on that stack after launch, with anything outside the tier priced before we do it. New build work carries a 90-day warranty; after that, care is how the product stays healthy.
Go live narrow, then earn the right to widen
Features we have safely deferred: fancy feeds, deep social graphs, premature mobile apps.
Recurring marketplace failure modes, from builds we have shipped:
- No supply density in the first category
- Take rates that insult vendors before value shows up
- Payout confusion
- Moderation gaps that trash quality
- Building for everyone in month one
- Search that cannot express how buyers actually choose
Liquidity work is ops and relationships. Code supports it; code does not replace it. Seed a tight geography or category until matching becomes measurably reliable, then widen. A national launch without supply density can underperform despite looking comprehensive.
Instrument the funnel from visit → listing view → start checkout → paid → fulfilled → payout early. Without those events you will argue about homepage taste while the leak sits in discovery or Connect onboarding drop-off.
Disadvantages and failure modes get an honest sibling: marketplace disadvantages.
What we’d do differently after 50+ marketplace builds
- Seed credible supply before public launch by default
- Decide charge type, fee copy and payout timing early
- Instrument the funnel from visit → listing view → transaction earlier
- Treat admin as a primary interface, not an afterthought
- Prefer a narrow category win over a national empty shell
- Put webhook and payout monitoring next to uptime from day one
- Put support routes in place on day one
We would also argue harder against “just ship mobile first”. A marketplace app is another client on the same API. The hard problems stay on the server - trust, payments and supply quality. Choose the first client surface around user behaviour, while solving trust, payments and supply quality in the shared domain model and API.
Frequently asked questions
How to develop a marketplace?
Develop a marketplace by securing first supply, mapping the transaction loop, deciding payments and connected onboarding early, cutting MVP to listing/discovery/checkout, hardening verification, disputes and moderation, launching narrow, then evolving from real liquidity data. Tools come after that sequence - not before.
Is it hard to build a marketplace app?
Yes relative to a brochure app, because shared state, payouts and trust flow across clients. It is manageable when the domain model and API already exist; painful when mobile is asked to invent the marketplace alone.
How much does it cost to start an online marketplace?
Our build cost is a fixed price agreed before build starts, with any changes priced before we do them. Senior developers direct AI agents through compressible implementation work; scope, evidence and the agreed fixed quote determine price. Full detail lives in the marketplace cost pillar.
How does a marketplace make money?
Common models include commission, listing or lead fees, seller subscriptions and hybrids. Choose using observable value, transaction economics, leakage and supplier economics; category alone does not dictate the model. Decide this alongside charge type and payout timing, not after sellers are already onboarded.
What’s the difference between a marketplace and a platform?
A marketplace connects independent supply and demand and supports some part of discovery or transaction. It may charge commission, fees or subscriptions; money flow or employment status alone does not determine the classification. A platform is the broader term: software other businesses build on top of, which may or may not involve a transaction. A marketplace is one type of platform, but not every platform is a marketplace.
What is embedded onboarding for Stripe Connect payouts?
Stripe embedded onboarding keeps users within the product and offers a low-integration-effort component; compare it with hosted onboarding based on UX, customisation and operating requirements. Stripe describes embedded onboarding as low effort.
Next step
If you’re weighing up building a marketplace, don’t start with wireframes. Start with credible evidence that real sellers will list before you write a line of code, then get the payment model and MVP scope settled before those decisions become costly to change.
The Marketplace Growth Review is a free 30-minute call that helps you judge whether your supply plan, transaction loop and payment model are ready to build. If you want it in writing, the Marketplace Growth Plan turns the same review into a fixed-price build plan, credited in full against your build if you go ahead. We’ve built 50+ marketplaces over 15+ years, from cannabis B2B trading to football sponsorship, so we can bring context from similar marketplace decisions.
Build the marketplace
Start with the workflows that make the model work.
We’ll map buyers, sellers, payments and operations before the build, backed by experience from more than 50 marketplace projects.
