Building a Two-Sided Marketplace: Lessons from Go Material and Jerni

Two-sided marketplace development means building two products at once, one for supply and one for demand, plus the matching, payments and trust layer that connects them. In India it also means GST tax collected at source, RBI escrow rules and split settlements. Get the supply side working first, then spend on demand.

We have built marketplaces on both sides of that problem. Go Material connects construction buyers with verified building material suppliers across Android, iOS and web. We go deeper into that category in our guide to construction procurement software in India. Jerni matches passengers with verified drivers and fleet vendors in real time. One moves cement and steel, the other moves people. The engineering problems turned out to be closer than either client expected.

This guide sets out what we learned: what to build first, where the Indian regulatory layer changes the architecture, and which decisions are expensive to reverse.

What two-sided marketplace development actually involves

A two-sided marketplace has two user groups who need each other and neither of whom will show up for an empty platform. That is the whole problem in one sentence. A single-sided e-commerce build has one catalogue, one checkout and one fulfilment path. A marketplace has:

• Two onboarding flows with different verification depth. Buyers need a phone number. Suppliers need GSTIN checks, bank account verification and document review.
• Two apps or two app modes, usually with separate release cycles.
• A matching layer, which is either search and filtering (Go Material) or live geospatial matching (Jerni).
• A payment split, because money arrives from one party and has to reach another minus your commission.
• An admin console that is not an afterthought. On both projects the admin panel was a first-class application with its own roadmap.

That is roughly three products, not one. Teams that scope a marketplace as “an app like X” underestimate it by the width of the admin console and the settlement logic.

Lesson 1: the supply side is the real product

On Go Material, the customer-facing promise is simple: discover verified suppliers, compare prices, check live stock and schedule doorstep delivery. Every one of those four things is a supply-side data problem. Price comparison is worthless if three suppliers have not updated their rates this week. Live stock availability is a liability if it is wrong, because a buyer who books cement that is not there does not come back.

So the supply tooling has to be good enough that a supplier with a laptop and patchy internet keeps it current. In practice that meant bulk upload, a low-friction rate update screen, and clear states for out of stock rather than silent zeroes.

Jerni has the same shape with a different unit. Supply is drivers, both independent drivers and fleet vendors, which is why the build included a separate vendor web application alongside the customer app and the admin panel. A fleet operator managing twelve cars does not want the driver app. They want a dashboard.

The practical rule: if you are choosing between one more buyer feature and one more supplier feature in your first release, ship the supplier feature. Buyers arrive when the supply is worth arriving for.

Lesson 2: matching is where the money goes

Matching is the part clients consistently under-budget. There are two families of it.

Catalogue matching, as in Go Material, is search, filters, location-aware availability and ranking. The hard part is not the search box. It is keeping the index consistent when supplier inventory, pricing and serviceable pincodes all change independently. We go deeper into that configuration model in our post on recycling app development and pincode-level architecture.

Real-time matching, as in Jerni, is a live geospatial problem. You are pairing moving vehicles with waiting passengers on a rolling window, then optimising the route. This is where third-party costs become a line item you have to model before you commit. Google’s published rates for the Routes API put Compute Routes Essentials at USD 5.00 per 1,000 requests with 10,000 Essentials calls free each month, and the Pro tier at USD 10.00 per 1,000. Volume pricing steps down above 100,000 monthly events.

Read that as a design constraint, not a bill. A naive implementation that recalculates routes on every driver location ping will call the API thousands of times per trip. A sane one batches, caches and only recomputes on meaningful deviation. The difference between the two is the difference between a viable unit economic and an unviable one.

Lesson 3: trust is a feature set, not a policy page

Both products lead with the word “verified”. That word has to be backed by something. On the mobility side, Jerni’s build includes OTP-secured ride start, live in-app tracking and a ratings system feeding the admin dashboards. On the materials side, verification means supplier document checks, GST-compliant invoicing and return management, because a buyer who receives the wrong grade of steel needs a route back to their money.

Trust features to budget from day one:

1. Identity verification on the supply side, with a manual review queue in admin. Automated checks fail, and someone has to adjudicate.
2. An OTP or handshake at the moment of exchange, so both sides confirm the transaction happened.
3. Ratings that admin can see, filter and act on. A rating nobody reads is decoration.
4. A dispute and return path with defined states, not an email address.
5. An audit trail of who changed what, which you will need the first time a supplier disputes a payout.

The Indian compliance layer you cannot skip

This is where an Indian marketplace diverges from the global tutorials. Four things change your architecture.

GST tax collected at source. Under Section 52 of the CGST Act, an e-commerce operator collects TCS on the net value of taxable supplies made through the platform, that is the taxable supply value minus returns. The rate was reduced from 1 percent to 0.5 percent with effect from 10 July 2024, split as 0.25 percent CGST and 0.25 percent SGST on intra-state supplies or 0.5 percent IGST on inter-state ones. GSTR-8 is due by the 10th of the following month. Operators must register for GST with no turnover threshold, and in every state where they operate. Practically, your order schema needs to carry place of supply, HSN, seller GSTIN and a returns linkage from the first migration, because retrofitting it is painful.

E-invoicing. The e-invoice mandate currently applies from ₹5 crore aggregate annual turnover, unchanged since 1 August 2023, and the test is the highest turnover in any financial year since 2017-18, not this year’s revenue. Sellers who cross it need an IRN on their invoices. If your platform generates invoices on a seller’s behalf, that flow is yours to build.

Payments and escrow. The RBI issued the Reserve Bank of India (Regulation of Payment Aggregators) Directions, 2025 on 15 September 2025, consolidating the earlier framework and rationalising PA categories into PA-Physical, PA-Online and PA-Cross Border. Non-bank payment aggregators need a minimum net worth of ₹15 crore at application and ₹25 crore thereafter, must hold merchant funds in escrow with a scheduled commercial bank, and must complete due diligence on merchants they onboard, with simplified checks available for small merchants below ₹40 lakh turnover.

The takeaway for most founders: do not try to become a payment aggregator. Use a regulated provider’s split settlement product. Razorpay Route, for example, splits an incoming payment across linked accounts and supports immediate transfer, deferred settlement or a custom hold period, with reversal handling for refunds. That hold period is the feature that matters in a marketplace, because it is how you keep money in reserve until delivery is confirmed.

DPDP. The Digital Personal Data Protection Rules were notified on 13 November 2025, with consent manager registration closing in November 2026 and full enforcement including penalties expected from May 2027. A marketplace holds two categories of personal data, and mobility platforms hold live location. Consent capture, purpose limitation and deletion need to be in the data model, not bolted on in 2027.

Two-sided marketplace development cost drivers

We do not publish fixed prices for a marketplace build because the range is genuinely wide, and anyone quoting a single number before scoping is guessing. Our post on what an MVP costs in India, broken down by stage sets out how we think about budget, and the same stage logic applies here. What is worth knowing is which decisions move the number:

• Number of apps. Buyer app, supplier or driver app, vendor web panel and admin console are four surfaces. Jerni needed an admin panel, a vendor web app and a customer web app. Every surface you add is design, build, QA and a release train.
• Real-time versus catalogue matching. Live matching adds sockets, geospatial queries, routing spend and a much harder test matrix.
• Payment complexity. Simple checkout is cheap. Split settlement with holds, partial refunds and commission reversals is not.
• Verification depth. Manual document review needs an admin workflow, an audit trail and an SLA.
• Inventory sync. If suppliers have their own systems, integrations dominate the estimate. If they use only your panel, they dominate your adoption risk instead.
• Regulatory surface. GST invoicing, TCS reporting and DPDP consent are real engineering, not paperwork.

For comparison on the app side alone, see our breakdown of mobile app development cost in India.

A build order that works

1. Admin and supply onboarding. Before any consumer sees the product, you need to add, verify and manage supply. Build this first.
2. Supply-side catalogue or availability tooling. Whatever the supplier updates daily, make it fast.
3. A single-city or single-category demand app. Constrain geography. Density beats coverage in every marketplace we have shipped.
4. Matching, then payments. Manual matching by an ops person is an acceptable version one. Manual payment reconciliation is not.
5. Trust and dispute flows. Ship these with your first real transactions, not after the first complaint.
6. Reporting and compliance exports. GSTR-8 data, settlement reports and audit logs, before your first GST filing deadline rather than during it.

ONDC’s growth is a useful reminder that Indian marketplace demand is not the constraint. The network reported crossing 500 million cumulative transactions in July 2026, roughly four years after its first live transaction in Bengaluru. The constraint is nearly always supply liquidity in a specific place.

Five mistakes in two-sided marketplace development

1. Launching both sides everywhere at once. Pick one city or one category. A marketplace with thin supply in ten cities is ten failed marketplaces.
2. Treating the admin panel as internal tooling. On both Go Material and Jerni the admin console carried verification, dispute handling and analytics. It deserves design time.
3. Building payment splits in-house. The RBI framework makes this a licensing question, not an engineering one. Use a regulated provider.
4. Modelling GST at the end. TCS, place of supply and returns have to be in the transaction schema from the start.
5. Ignoring the cost per match. Routing and maps spend per transaction determines whether your take rate works. Model it before you build.

If your marketplace also needs a sales or supplier relationship layer, our comparison of custom CRM versus off-the-shelf for Indian SMBs covers when to build and when to buy.

Talk to us about your marketplace

If you are scoping a marketplace and want an honest view of what the first release should contain, what it will cost and which parts of the Indian compliance layer apply to you, we can help. AY Technologies builds marketplace platforms from New Delhi for clients across construction, mobility, home services and commerce. If your marketplace matches customers with service professionals, our home services app development playbook covers booking flows, job routing and the 2026 compliance layer. See our custom software development services or send us your requirement and we will come back with a scoped build plan rather than a number pulled from the air.