Building a multi-vertical delivery platform in India

Delivery app development in India is four products, not one: the customer app, the merchant app, the rider app and the operations console, all on a backend that dispatches in real time, settles through UPI and survives the evening of a festival. Making it multi-vertical, so that food, grocery, pharmacy and parcels run on the same platform, is mostly a matter of deciding early which parts are shared and which belong to a vertical. This article lays out the surfaces, the backend, the India-specific pieces and the sizing decisions, drawn from our super app development and logistics work.

What a hyperlocal delivery platform actually contains

The customer app is the visible part and the smallest share of the engineering. Behind it sit the merchant tools that keep the catalogue and accept orders, the rider app that runs on cheap Android phones over unreliable networks, the dispatch engine, the settlement system that pays merchants and riders correctly, and the operations console where a small team manages exceptions across a city. Each has its own users, failure modes and release cadence.

The four surfaces and what each must do

Multi-vertical: what is shared and what is not

Shared: identity, addresses, wallet and payments, notifications, the order lifecycle, dispatch, rider management, settlements, support and the operations console. Vertical-specific: catalogue structure, availability rules, packaging and handling requirements, pricing rules, and compliance. A pharmacy order needs a prescription check and a licensed merchant; grocery needs substitutions and weight-based items; food needs preparation-time estimates; parcels need pickup scheduling and size classes.

The shared backend is built once as services with a vertical type on every order. Each vertical then contributes a catalogue model and a fulfilment ruleset. Done this way, the second vertical is a few weeks of work rather than a second platform. The layering follows the pattern in super app architecture: shell, modules and shared services.

Real-time dispatch and the rider app

Dispatch is the heart of the platform. It batches orders by area and time window, proposes an assignment for each using distance, rider load, vehicle type and merchant readiness, and lets operations override on a live map. It must handle the rider who goes offline mid-delivery, the merchant who is late, and the customer who moved the pin. The engine design is covered in dispatch and routing engines.

The rider app is where most Indian delivery platforms are won or lost. Riders use inexpensive phones with limited storage and patchy data. The app must queue every action locally and sync when connectivity returns, so a proof-of-delivery photo taken in a basement is not lost. It should hand off to a maps application for navigation rather than reinventing it, show earnings transparently, and never require a working connection to mark a stop complete. We built exactly this for a last-mile operator; the dispatch platform and offline-first driver app case study describes the trade-offs.

UPI payments, wallets and settlements

Customers expect UPI as the default, with cards, wallets and cash on delivery behind it. The platform integrates a payment gateway that supports UPI intent and collect flows, handles the pending state that UPI sometimes leaves an order in, and reconciles gateway settlements against orders daily. The NPCI UPI product overview is the primary reference for the rail; the gateway documentation covers the integration specifics.

Settlements are the part founders underestimate. Every order splits into merchant payout, rider earnings, commission, discounts, taxes and sometimes a tip, and each party expects payment on a schedule with a statement they can check. Build the ledger from the first order, with every split an immutable entry, and generate statements from it; retrofitting a ledger after a year of orders is painful. The wider design is in wallets, UPI and payments in super apps.

Sizing for festival peaks

Indian demand is spiky in ways other markets are not. Diwali week, New Year's Eve, a cricket final and a monsoon downpour all concentrate several evenings' worth of orders into a couple of hours. The backend is sized for that evening, not the average day, and the components that fail first under load are always the same: dispatch, notifications and payment callback handlers.

The answers are ordinary but must be done in advance: horizontally scaled stateless services, a queue between order creation and dispatch so a burst is absorbed rather than dropped, graceful degradation that pauses new orders in an area rather than failing them, cached catalogue and merchant status, and a load test against a production copy before every known peak. Operations also needs a control to widen delivery windows or close areas when riders are short, which is a product feature, not infrastructure.

Merchant and rider onboarding as products

A delivery platform has two supply sides, and both need onboarding that scales without a field team visiting every shop. Merchant onboarding covers documents, bank details, catalogue upload, and training on the merchant app; rider onboarding covers identity, vehicle, bank details and a first supervised shift. Both should be self-serve with a verification queue in the operations console. Document checks are a good early use of AI, following the approach in the KYC document intelligence case study. The full pattern is in merchant and partner onboarding as a product.

Where AI earns its place

Not in the first release, except for document verification and address normalisation, which remove manual work immediately. Later: ETA prediction from historic delivery times, demand forecasting per area for rider scheduling, exception agents that call a customer when a rider is stuck, and support agents for the where-is-my-order conversation. Each depends on event data collected from day one, which is the argument for building the event pipeline early.

A worked example

A regional grocery chain in a tier-two city ran deliveries through a WhatsApp number and a few hired riders, then decided to build a platform and add food from partner restaurants and a pharmacy line. The temptation was a customer app first. The Sprint Zero instead ordered the work around supply: merchant app and catalogue, rider app with offline sync, dispatch and the operations console, then the customer app on top.

Grocery went live first on the chain's own stores. The restaurant vertical followed as a catalogue model and a preparation-time rule on the same order and dispatch services. Pharmacy added a prescription-upload step and a licensed-merchant flag. UPI ran through a gateway with daily reconciliation into a ledger that produced merchant and rider statements. Before the first Diwali, a load test against a production copy found the notification service as the bottleneck, which was fixed with a queue. The company added a WhatsApp ordering channel later, in the manner of the personalisation and WhatsApp agent case study, because the backend was already an API.

Team and timeline

A first release with one vertical and all four surfaces is a product lead, a mobile lead and two mobile engineers, a backend lead and three backend engineers, a designer, a DevOps engineer and a QA engineer. Your side owns merchant and rider recruitment, city operations and the pricing decisions.

That first release is a super app development engagement from $63,000 (₹41.6L), typically sixteen to twenty-four weeks. A single-vertical platform without the multi-vertical backend can be scoped under product and platform development from $42,000 (₹28L). Each additional vertical is usually a few weeks of catalogue and rules work. A Sprint Zero at $3,250 (₹2,00,000) sets the order of build and the shared-versus-vertical split, and is credited to the build. Running the platform through peaks needs the Enterprise Care Plan at $5,250 (₹3,40,000) a month with a named engineer; see the pricing page and the logistics industry page.

Before you start: a checklist

• Decide the first vertical and the first city, and recruit supply before the customer app exists
• Write the shared-versus-vertical split for catalogue, rules, dispatch and settlement
• Confirm the rider app will work offline on the cheapest phones your riders own
• Choose the payment gateway for UPI intent and collect, and plan daily reconciliation
• Design the settlement ledger before the first order is placed
• Define the peak-day scenario the backend will be load-tested against
• Plan merchant and rider onboarding as self-serve flows with a verification queue
• Instrument events from day one so ETA and forecasting models are possible later

Questions clients ask

• Should we launch with food or grocery? Whichever supply you can recruit and control; owned stores are easier than partner restaurants for a first release.
• Can we use a white-label delivery product instead? For a single vertical in one city, perhaps; multi-vertical with your own dispatch rules usually outgrows them within a year.
• How do we handle cash on delivery? As a payment method in the ledger with rider cash-in-hand tracking and daily deposit reconciliation.
• When do we need AI? Document verification and address cleanup at launch; ETA, forecasting and support agents once you have a few months of data.

Related reading

Continue with what is a super app and should you build one, AI in logistics: dispatch, exceptions and customer updates, and the React Native mobile service for the rider and customer apps.

Build supply first, share the backend across verticals, size for the festival evening, and the customer app becomes the easy part.