Two people accept the same job
Naive dispatch sends an order to everyone nearby. Two accept, one gets a stuck screen, and the platform loses a partner.
On Demand
On demand app development, from dispatch logic to partner payouts
Three apps, one system. A customer app that finds what is nearby. A partner app that works on a cheap Android phone in bad network. An operations console where somebody can see why an order is stuck.
5 solution blueprints
19 systems we integrate
12–22 weeks, typical build
The starting point
What is usually broken before we arrive
Friday payouts never balance
Cash, UPI and card all settle differently. Without a ledger, reconciling partner earnings becomes a spreadsheet argument every week.
The rider app dies in a basement
Deliveries happen in lifts, parking levels and industrial estates. An app that needs connectivity to log a drop will not get used.
In plain terms
On demand app development is building a platform that matches a customer request to an available provider in real time. Food and grocery delivery, home services, rides, rentals or equipment hire. It is normally three connected apps: one for customers, one for partners, and an admin console for dispatch, pricing, payouts and disputes.
The demo version takes a few weeks. The version that survives a real Saturday evening takes much longer. The difference is almost never the customer app.
Dispatch is where the engineering sits. Nearest-partner matching is the naive version. A working allocator weighs distance, acceptance history, current load, vehicle type and order age, then retries in a defined sequence. Get it wrong and partners quietly leave.
The other half is money. Payouts, commission slabs, cash reconciliation, refunds on partial deliveries. All of it has to agree with the ledger every single day. Indian payout rails also sit under RBI rules that decide how funds may be held, so this shapes the architecture.
What we build
On Demand systems, and who builds each one
Every card links to the practice that does the work. Follow one if you want the detail.
Customer, partner and admin apps
React Native apps for both sides of the marketplace, plus the web console where operations staff fix the day problems.
ExploreDispatch and matching engine
Allocation weighted by distance, load, acceptance history and order age. Defined retry sequences, multi-drop batching, manual override for the ops desk.
ExplorePayments, wallets and payouts
Order payment, wallet top-up, cash reconciliation, commission slabs and scheduled payouts that agree with the ledger every cycle.
ExploreMulti-vendor and ONDC-ready catalogues
Vendor onboarding, catalogue and stock sync, per-vendor pricing and serviceability zones. Joining ONDC becomes configuration, not a rebuild.
ExploreOperations and unit economics
Orders by zone and hour, partner utilisation, acceptance and cancellation rates, delivery time spread, and contribution margin per order.
ExploreAutomated support and order bots
WhatsApp and in-app assistants that answer "where is my order", handle refunds within policy, and hand off to a human with full context.
ExploreLaunch marketing for a new city
City-level acquisition for both sides of the marketplace, measured on first completed order and activated partners instead of installs.
Explore Solution blueprints
Open one and see exactly what gets built
The situation it answers, the architecture, every module, the systems it plugs into and how long it takes. These describe our work, not one client's project. Named clients with measured results are in the case studies.
01 Hyperlocal delivery marketplace 16–22 weeks
The situation
An operator aggregating neighbourhood stores inside a fixed radius, with its own rider fleet. Orders arrive on WhatsApp. A coordinator assigns riders by phone. Nobody knows the true cost of a delivery once incentives and failed drops are counted.
How it is built
React Native customer and rider apps on a Node.js API. PostgreSQL with PostGIS holds serviceability polygons, Redis runs the live dispatch queue, and a WebSocket channel carries rider location and order state to the ops console.
Rules it has to follow
Split settlement to stores runs through an RBI-regulated payment aggregator, never a pooled operator account. Rider identity is verified at onboarding through DigiLocker. Cash balances are reconciled against deposits daily.
Modules 10
- Serviceability zones and store-level delivery radius
- Store catalogue with live availability and slot control
- Cart, promotions and delivery-fee rules
- Dispatch engine with weighted allocation and retry
- Rider app with navigation, proof of delivery and cash collection
- Live order tracking for customer and operations
- Cancellation, partial refund and dispute handling
- Rider incentives, shift planning and attendance
- Store settlement and commission statements
- Operations console with manual reassignment
Plugs into
- Google Maps Routes API
- Razorpay Route
- Firebase Cloud Messaging
- WhatsApp Business API
- MSG91 DLT SMS
02 Home services booking platform 14–18 weeks
The situation
An aggregator covering electricians, plumbers, appliance repair and cleaning, where jobs are scheduled instead of instant. The real problems are quality control, no-shows on both sides, and quoting before anyone has seen the job.
How it is built
React web and React Native apps on a Node.js service layer. The scheduling engine reserves professional time against skill, travel time between jobs and part availability. Quote revisions keep the customer approval on record.
Rules it has to follow
Background verification for professionals entering customer homes is retained with consent and re-checked on a fixed cycle. Work cannot continue past a revised quote without recorded customer approval, which is what makes a disputed bill resolvable.
Modules 10
- Service catalogue with fixed-price and inspection-first jobs
- Professional onboarding, skill tagging and background verification
- Slot scheduling with travel-time buffers
- On-site quote revision with customer approval capture
- Spare-parts catalogue and consumption per job
- Job checklist with before and after photographs
- Warranty tracking and free revisit windows
- Rating, penalty and reinstatement workflow
- Professional earnings, deductions and payouts
- Recurring service subscriptions (AMC)
Plugs into
- Cashfree Payouts
- DigiLocker KYC
- Google Places Autocomplete
- WhatsApp Business API
- Firebase Cloud Messaging
03 Ride and fleet dispatch 16–20 weeks
The situation
An operator running airport transfers, employee transport or intercity cabs across owned and attached vehicles. Bookings come by phone and app. Allocation is manual. Corporate clients want monthly invoices reconciled against trip logs nobody can produce.
How it is built
Android-first driver app built for cheap devices, with offline trip capture. Node.js dispatch service using Redis geospatial indexes. A React corporate booking portal carrying cost-centre hierarchies and approval workflows.
Rules it has to follow
Licence, permit, fitness and insurance expiry are checked against VAHAN and block allocation once lapsed. Trip data retention and the SOS escalation path follow the aggregator conditions of the operating state.
Modules 10
- Vehicle, driver and document expiry register
- Instant and scheduled booking with fare estimation
- Weighted dispatch with driver acceptance windows
- Live trip tracking with route replay
- Fare engine: distance, waiting, night and toll components
- Corporate accounts with cost centres and approvals
- Employee transport rostering and route planning
- Driver earnings, commission and settlement
- Trip-log reconciliation and monthly corporate invoicing
- SOS, speed and harsh-driving alerts
Plugs into
- Google Maps Directions API
- FASTag toll data
- VAHAN document verification
- GPS telematics devices
- Razorpay
04 Multi-vendor food ordering, ONDC ready 14–20 weeks
The situation
A restaurant group or city food aggregator that wants its own ordering channel instead of paying marketplace commission on every order. It also wants the option of taking ONDC network orders alongside its own.
How it is built
A headless catalogue service with per-outlet menus and timings. Node.js order orchestration puts first-party and network orders through the same state machine. The kitchen display needs no keyboard.
Rules it has to follow
FSSAI licence numbers are held per outlet, displayed where required, and alerted before expiry. ONDC participation follows the network catalogue and order protocol, so listings and cancellations behave the way the network expects.
Modules 10
- Outlet-level menu, timing and item availability
- Modifiers, combos and portion variants
- Cart with offers, coupons and loyalty redemption
- Kitchen display with preparation-time tracking
- Rider assignment or third-party delivery handoff
- ONDC protocol adapter for catalogue and order flow
- FSSAI licence and outlet compliance register
- Refund and complaint resolution workflow
- Outlet settlement and commission statements
- Repeat-order and win-back campaigns
Plugs into
- ONDC network protocol
- Razorpay
- Shiprocket / third-party rider APIs
- WhatsApp Business API
- Petpooja / POS sync
05 Rental and equipment booking 12–16 weeks
The situation
An operator renting physical assets by the hour, day or month. Two-wheelers, construction equipment, event gear or workspace. The constraint is availability across overlapping bookings, plus deposits, damage assessment and the paperwork of handing an asset to a stranger.
How it is built
An interval-based reservation engine with buffer windows for servicing and transport, on Node.js and PostgreSQL. A condition-report module captures timestamped photographs at handover and return.
Rules it has to follow
Rental agreements are generated per booking and signed through Aadhaar e-signature where the asset class needs it. Customer identity documents are stored encrypted with a defined retention period, not left in a shared drive.
Modules 10
- Asset register with category, condition and service history
- Interval availability with maintenance and transit buffers
- Hourly, daily and monthly rate cards with seasonal pricing
- KYC capture and agreement generation
- Security deposit hold, deduction and release
- Handover and return condition reports with photographs
- Damage assessment and chargeback workflow
- Late-return penalty and extension handling
- Preventive maintenance scheduling per asset
- Utilisation and idle-time reporting by asset
Plugs into
- DigiLocker KYC
- Razorpay
- eSign / Aadhaar e-signature
- Google Maps Geocoding API
- GPS trackers on high-value assets
Regulation
What on-demand software has to comply with in India
Get these wrong and the build is not late, it is unusable. They are design inputs on day one.
RBI payment aggregator rules
A marketplace collecting on behalf of vendors cannot pool those funds in its own current account. Settlement has to run through a licensed payment aggregator with escrow and split settlement. That changes how the ledger and payout scheduling are designed, not just which SDK you install.
ONDC network protocol
Joining the Open Network for Digital Commerce means implementing the network catalogue, order, fulfilment and issue-resolution flows instead of an in-house API shape. Build the catalogue and order state machine that way from the start and joining becomes configuration.
Partner KYC and background checks
Riders, drivers and home-service professionals need identity verification before they get work, and some categories need a documented background check. DigiLocker keeps this auditable. Re-verification cycles matter as much as the first check.
DLT registration for SMS
Transactional SMS in India needs the sender ID and every template registered on a DLT platform before delivery. Order and OTP templates should be registered during the build, not discovered on launch day when messages silently fail.
Motor vehicle and aggregator conditions
Ride and delivery operations using motor vehicles fall under state-level aggregator conditions covering driver documentation, fare display, grievance handling and safety features. Tracking expiry against VAHAN keeps ineligible vehicles out of allocation automatically.
Why Naryon Tech
How we approach on-demand projects
- The dispatch engine is the productWe design allocation, retry and override logic before drawing a single screen. It decides whether partners stay. Everything else is easier to change later.
- Built for cheap Android and bad networkThe partner app is tested on low-end phones and throttled connections, with queued actions and offline capture. That is the device the platform actually runs on.
- Money is a ledger, not a status columnOrder value, commission, incentives, refunds and cash collection are double-entry from day one. Settlement disputes become a query instead of an argument.
- Unit economics visible from launchContribution margin per order, after rider cost, incentives, payment charges and failed deliveries, sits on the dashboard from the first week. Nobody scales a loss by accident.
Tooling
What we build on-demand systems with
Apps
- React Native
- React
- TypeScript
- Expo
Services
- Node.js
- PostgreSQL + PostGIS
- Redis
- WebSockets
- BullMQ
Location & messaging
- Google Maps Platform
- Mapbox
- Firebase Cloud Messaging
- WhatsApp Business API
Money
- Razorpay Route
- Cashfree Payouts
- Double-entry ledger
- Reconciliation jobs
Working from Chennai and Trichy, with clients in
- Chennai
- Tiruchirappalli (Trichy)
- Coimbatore
- Madurai
- Salem
- Erode
- Tirunelveli
- Vellore
- Tiruppur
- Puducherry
Straight answers
On Demand: what people ask us first
How long does an on-demand platform take to build?
A single-city platform with customer app, partner app, dispatch and payouts usually takes fourteen to twenty-two weeks. Home services and rentals sit at the lower end, because scheduling forgives more than live dispatch. Delivery and ride platforms sit at the top, because allocation, tracking and settlement all have to work on the first busy evening.
Should we just use a ready-made clone script?
For testing demand in one locality, sometimes yes, and we will say so if that is where you are. It breaks the moment your dispatch rules, pricing or settlement must differ from what the script assumes. You are then rewriting inside somebody else's codebase, which usually costs more than building it properly.
How do payouts and cash collection reconcile?
Every order writes ledger entries for order value, commission, taxes, incentives and any cash the partner collected. The payout run settles against that ledger, not against order counts, so a partner statement traces back to individual orders. Cash balances reconcile daily against deposits, and that is where problems surface first.
Can the platform join ONDC later?
Yes, if the catalogue and order state machine follow that shape from the start, which is how we build them by default. Joining then means writing the protocol adapter and completing network onboarding. Retrofitting it onto a platform built around a bespoke API is considerably more work.
What happens when two partners accept the same order?
Each partner in the retry sequence gets a short exclusive lock, so only one acceptance can win and the second sees a clear rejection instead of a frozen screen. Orders that exhaust the sequence escalate to the ops console for manual assignment. Silent looping is the failure mode that loses customers.
Do you handle launching a second city?
The platform is multi-city from the start. Serviceability zones, pricing, partner pools and settlement are all scoped per city instead of being global constants. Adding a city becomes configuration plus supply acquisition. We can run the acquisition side too, measured on activated partners and first completed orders.
Close to this
Related industries
Building something for on-demand?
Tell us the workflow that keeps breaking. We will say honestly whether software fixes it, and what it would take.