Marketplace development: supply, demand and the boring plumbing
What should you know about marketplace development before you commission a build?
Marketplaces succeed on supply onboarding, payments and settlement, trust and disputes; the storefront is the easy part. Budget most of the build for the seller side, the ledger and operations tools, and treat the buyer app as the thin layer it is. Here is what the plumbing contains, what it costs and who builds it.
Marketplace development is mostly not about the storefront. The listing page, the search bar and the checkout button are a few weeks of work and every agency can show you a handsome one. What decides whether a two-sided marketplace survives its first year is the part buyers never see: how sellers get onboarded and paid, how money moves and reconciles, how disputes are settled, and how a small operations team keeps thousands of transactions honest without drowning. This article walks through that plumbing so you can scope and budget a marketplace platform in India properly, and know which parts to build first.
Why the storefront is the easy part
A buyer-side app has one user type, one happy path and mature design patterns to copy. A marketplace has at least three user types (buyers, sellers, your own operations staff), money that belongs to someone else passing through your accounts, and a trust problem on both sides from day one. The engineering effort follows the complexity: in the marketplaces we have built, the seller tools, ledger and operations console together take more calendar time than the buyer experience, and they are where the late surprises live.
The framing we use with clients is simple. Demand is a marketing problem you can spend on. Supply is an onboarding and payout problem you have to engineer. Trust is a product problem you must design in before the first dispute, because retrofitting it means changing the data model.
The six subsystems of a two-sided marketplace build
| Subsystem | What it contains | Why it is underestimated |
|---|---|---|
| Seller onboarding | Sign-up, KYC and bank verification, catalogue upload, pricing rules, approval workflow | Every manual step here becomes an operations hire later |
| Catalogue and search | Categories, attributes, variants, stock, moderation, search and ranking | Messy seller data breaks search; moderation is a queue, not a feature |
| Orders and fulfilment | Cart, order states, split orders across sellers, shipping or service scheduling | One order can become several shipments with separate states |
| Payments and settlement | Collection, wallet or escrow ledger, commissions, payouts, refunds, reconciliation | Money that is not yours needs an auditable ledger |
| Trust and disputes | Ratings, verification badges, dispute flow, evidence, resolution rules, fraud signals | Rules must exist before the first dispute, not after |
| Operations console | Seller management, order intervention, payout holds, reports, audit log | Nobody budgets for it; everybody needs it in week one |
Supply onboarding decides growth
Most marketplaces stall because adding sellers costs more than sellers are worth for the first months. If each new seller needs a phone call, a spreadsheet and a manual catalogue import, growth is bounded by the size of your operations team. Self-serve vendor onboarding is what removes that ceiling: identity and bank verification through APIs, a catalogue import that tolerates imperfect data and flags what it cannot map, and an approval queue with clear reasons for rejection. We cover the product thinking in merchant and partner onboarding as a product.
The seller app is a real product
Sellers need to manage stock, accept or reject orders, see their earnings, and understand why a payout was held. If the seller tools are an afterthought, sellers manage on WhatsApp and your data goes stale. Budget the seller experience as a second product with its own design pass, not a settings page bolted onto the admin.
Payments and settlement: the ledger comes first
A marketplace collects money from buyers, holds it, deducts commission and fees, and pays sellers on a schedule, while also handling refunds, partial refunds, cancellations after payout and chargebacks. The only sane way to build this is a double-entry ledger that records every movement between buyer, platform, seller and gateway, and a settlement job that reads from it. Gateway payouts, commission reports and GST invoices are then views over the ledger rather than separate sources of truth.
In India the practical rails are UPI, cards and wallets through a gateway that supports route or split payouts. Razorpay documents its marketplace payout flows on the Razorpay developer site, and the settlement rules there shape how your ledger must represent holds and releases. Our companion article on wallets, UPI and payments in super apps goes deeper on the ledger design; the short version is that reconciliation between your ledger and the gateway's statements is a daily job that must be automated from launch.
Trust and disputes are product decisions
Write the dispute rules before the build starts. Who can raise a dispute, within how many days, what evidence is required, who decides, what happens to the seller's payout while it is open, and what the seller can appeal. Each of those answers becomes a state in the order model and a screen in the operations console. Ratings need protection against retaliation and manipulation, which usually means both sides rate blind and reviews are tied to completed transactions only.
Fraud on marketplaces takes predictable shapes: fake sellers collecting advance payments, buyers claiming non-delivery, collusion to farm ratings. You do not need a machine-learning model on day one, but you do need the signals captured (device, payment instrument, address patterns, velocity) so that rules can be added quickly and a model trained later. Our AI/ML development team often adds that model in the second or third quarter once there is data.
Search, ranking and the cold-start problem
Search on a young marketplace is hard because the catalogue is thin and inconsistent. Invest in structured attributes and category rules at onboarding rather than in clever ranking; good data beats a good algorithm when there are only a few thousand listings. Ranking can start with simple, explainable rules (in stock, seller rating, proximity, freshness) and move to learned ranking when there is enough behaviour to learn from.
The operations console nobody budgets for
From the first week, someone on your team will need to find an order, see its full history, contact the seller, hold a payout, issue a partial refund and export a report for finance. Every one of those is a screen or an action with an audit trail. Build the console alongside the customer-facing product, with role-based access and a log of who did what, because it is also the tool that keeps your marketplace compliant when a regulator or a bank asks questions.
A worked example
A services marketplace connecting small workshops with business customers came to us with a polished buyer app from a previous vendor and a growth problem. Onboarding each workshop took a member of staff most of a day, payouts were run from a spreadsheet, and disputes were settled by whoever picked up the phone. We rebuilt the supply side first: self-serve onboarding with bank verification, a catalogue template the workshops could actually fill in, and an approval queue. Then a ledger with scheduled payouts and automated reconciliation against the gateway. Then a dispute flow with evidence upload and payout holds. The buyer app barely changed. Onboarding moved from staff-led to self-serve, the finance team stopped reconciling by hand, and the operations team spent its time on exceptions rather than routine. The same pattern of building the unglamorous layer under an existing front end is described in our dispatch platform and driver app case study.
Team and timeline
A marketplace at this scope is usually a product lead, a backend engineer who owns the ledger and order model, a full-stack engineer for the seller and operations tools, a mobile or web engineer for the buyer side, and a designer, working for twelve to twenty weeks depending on categories and payment complexity. It sits under our super app and marketplace development service, with pricing from $63,000 / ₹41.6L for a full platform; a narrower single-category marketplace often fits SaaS development from $31,500 / ₹20.8L. Where the scope is uncertain, a ten-day Sprint Zero at $3,250 / ₹2,00,000 produces the order model, dispute rules and a fixed quote, and is credited to the build. Full details are on the pricing page.
Before you start: a checklist
- Write the seller onboarding steps and mark which can be automated with KYC and bank APIs
- Draw the order state machine including split orders, cancellations and partial refunds
- Decide the settlement schedule, commission model and how holds work
- Write the dispute rules: who, when, evidence, decision, appeal
- List the operations console actions your team needs in week one
- Choose the payment gateway based on payout and split support, not just checkout
- Agree what data you capture from day one for fraud rules later
- Decide the catalogue attributes per category before any seller uploads
Glossary
- Two-sided marketplace: a platform where independent sellers and buyers transact, with the platform taking a fee
- Settlement: the scheduled transfer of collected money to sellers after commissions, refunds and holds
- Ledger: a double-entry record of every movement of money between parties on the platform
- Payout hold: money kept back from a seller pending a dispute, verification or return window
- Split payment: a single buyer payment routed to several sellers and the platform
- Cold start: the period when a marketplace has too few listings or buyers for search and ranking to work well
Related reading
Start with what a super app is and whether you should build one if the marketplace is one module of a larger app, then super app architecture for the shell and shared services, and peak-load engineering for consumer apps before your first sale event. For payouts, the NPCI documents the UPI rails your gateway will sit on.
Build the plumbing first and the storefront last; the marketplaces that survive are the ones whose sellers get paid correctly and on time.
Frequently asked questions
How long does marketplace development take?
▾
Twelve to twenty weeks for a full two-sided platform with seller onboarding, ledger, disputes and operations tools; a single-category marketplace with simple payouts can be shorter. See super app development.
Should we use a marketplace SaaS instead of building?
▾
If your model is standard retail with simple commissions, yes to start. Build when payouts, disputes or the seller workflow are the product, because those are what SaaS tools make hard to change.
What does a marketplace platform cost in India?
▾
Full platforms start from $63,000 / ₹41.6L under our super app service; narrower builds from $31,500 / ₹20.8L. A fixed quote comes from a ten-day Sprint Zero. Details on the pricing page.