Building a marketplace, including the parts nobody demos
A marketplace connects sellers and buyers, taking a fee on transactions. The software is the straightforward part. The hard parts are vendor onboarding and verification, splitting payments and handling payouts, resolving disputes, and solving the problem of having neither buyers nor sellers at launch.
Marketplace builds are usually scoped as a store with multiple sellers, which underestimates them substantially. A store has one party responsible for the product. A marketplace has many, most of whom you have never met, and your platform is answerable to the buyer for what all of them do.
The parts that get left out of scope are the parts that determine whether the thing works. Payment splitting sounds like arithmetic and involves regulated money flows, payout schedules and what happens to funds during a dispute. Vendor verification is a fraud problem. Reviews are a trust problem with a gaming problem attached. And the cold start, no sellers because no buyers, no buyers because no sellers, is a business problem software cannot solve.
When this work makes sense
Questions worth asking any supplier
Which side of the market do you already have? Building both from zero simultaneously rarely works.
How will money flow, and are you comfortable with what holding funds implies?
Who is responsible when a transaction goes wrong? That answer shapes the whole platform.
How are vendors verified? An unverified marketplace attracts exactly the sellers you do not want.
What is the take rate, and does the unit economics work at realistic volume?
Deliverables
Vendor onboarding with verification steps proportionate to the risk
Vendor dashboards for listings, orders, fulfilment and earnings
Buyer experience with search and filtering that works across many sellers
Payment splitting using a provider's marketplace facilities rather than handling funds yourself
Payout scheduling with handling for disputes and held funds
Review and rating systems with manipulation resistance considered
Dispute and refund workflow with defined responsibilities
Admin tooling for moderation, vendor management and transaction oversight
Built with
Process
Money flow is designed before anything else, because it constrains the entire platform and carries regulatory weight, who holds funds and for how long, when a vendor is paid, what happens during a dispute, and whether your business is holding customer money, these determine the payment provider, the platform architecture and possibly your regulatory position. Deciding them after the product is built is the most expensive sequence available.
The standard nine stages, discovery, strategy, UX/UI, development, content and SEO, testing, launch, measurement and continuous improvement, apply to every project. The paragraph above is what differs for this one.
What moves the number
Pricing depends on scope, functionality, integrations and content requirements. These are the factors that change it most:
Marketplace software, custom build, or starting manually
Off-the-shelf marketplace software
Fits: Conventional models where the platform's assumptions match yours
Limits: Its assumptions about payouts and fees may not match; customisation is often limited
Custom build
Fits: Validated models with specific requirements around money or verification
Limits: Largest investment before revenue, and the non-software problems remain
Manual operation first
Fits: Testing whether the market exists before building anything
Limits: Does not scale, which is the point. It tells you whether scaling is worth funding
Case studies
No published marketplace case study.
MBGDesk operates from 4 offices in India, United States, United Kingdom, United Arab Emirates. We hold no industry certifications and do not imply otherwise.
Frequently asked questions
How do we solve the cold start problem?
Not with software. Most successful marketplaces started by manufacturing one side, recruiting sellers manually, or serving buyers themselves before suppliers existed. If your plan is to launch and let both sides arrive, that is the part of the plan most likely to fail, and it is not a thing we can build.
How does payment splitting work?
Through a provider's marketplace facility, Stripe Connect, Razorpay Route or similar, which handles splitting and payouts without your business holding customer funds. Building it yourself means holding money on behalf of others, which carries regulatory implications you should take advice on.
Should we launch as an MVP?
Usually, and often more manually than founders expect. Several substantial marketplaces ran their early matching by hand, because doing it manually tells you what the software actually needs to do. Building the full platform first means building it on assumptions.
How do we stop fake reviews?
Verify reviews against completed transactions, so only actual buyers can review. It does not eliminate manipulation and it removes the easiest route. Unverified reviews on a marketplace degrade quickly and take the platform's credibility with them.
Who is liable when a vendor does not deliver?
That is a legal question for your counsel and it shapes the product. Your terms define it; buyers tend to hold the platform responsible regardless of what the terms say, so the dispute process needs designing as a real workflow rather than an email address.
What take rate is realistic?
It varies enormously by category and by what the platform does for each side. The relevant test is whether it covers payment costs, moderation, support and development at a volume you can realistically reach, modelled before building, not discovered after.
Can we start with a directory instead?
Frequently the right first step. A directory with no transactions tests whether demand exists without the payment, dispute and payout complexity. If people are finding and contacting vendors, transactions are a logical next build rather than a bet.
Services that connect to this
Talk to us about this
Tell us what you are trying to build and we will come back with scope, approach and an estimate.