On-Demand App Development Guide: Three Apps, Dispatch, Payouts and Launching City by City

What "on-demand" means in software

Food delivery, grocery delivery, ride-hailing, home services and courier apps share a structure: someone asks for something now, the platform finds a provider nearby, tracks the job live, takes the payment and pays the provider. The screens differ; the system underneath is the same. Founders often budget for the customer app they can picture and forget the other three parts, which are where most of the hours and most of the operational pain sit.

What it costs

These come from our app development cost calculator presets, with a senior offshore team of 3 senior full-stack engineers, a mobile engineer, a designer (part-time), QA and a delivery lead. The detailed breakdowns are in cost to build a food delivery app like DoorDash, cost to build an app like Uber and cost to build an app like Instacart. Grocery costs more because of catalogue feeds, substitutions and chat between shopper and customer.

Dispatch: matching jobs to providers

Dispatch is the heart of the system. The MVP does not need an optimisation engine; it needs rules that work and a human override. Start with: find online providers within a radius of the pickup, rank by estimated time to arrive, offer the job to one provider at a time with a short timeout, then move to the next. For food, delay the offer until the restaurant is close to ready, so couriers do not wait at the counter. Batch two orders for one courier only when pickups are close and the second customer will not wait long.

• Location updates from provider apps every few seconds while on a job, less often while idle, to save battery and cost.
• A geospatial index (PostGIS or Redis geo) to find nearby providers quickly.
• Travel-time estimates from a routing API (Google Maps Platform, Mapbox, HERE) rather than straight-line distance.
• A dispatcher screen where your operations team can reassign a job by hand. In the first months they will, often.

Payments and payouts

The customer pays once; the money splits three ways: the merchant, the provider and the platform. Use a marketplace payments product (Stripe Connect, Adyen for Platforms) so providers and merchants are onboarded and verified by the payment provider, and payouts run on a schedule. Keep your own ledger of every order's split, tips, refunds and adjustments, because providers will ask why a week's earnings changed. Tips must go to the provider in full, and many jurisdictions now set minimum pay rules for app-based workers; check the city before you design the pay model. Our Stripe Connect marketplace guide covers account types and payout timing.

Launching city by city

On-demand marketplaces are local. A customer in one city gets nothing from providers in another, so density matters more than coverage. Launch in one city, or one part of one city, and stay there until orders per provider hour and delivery times are where you need them.

1. Pick a zone small enough to keep delivery times short: a few neighbourhoods with enough merchants and demand.
2. Recruit supply before demand: merchants signed and providers onboarded before you spend on customer acquisition.
3. Configure zones, fees and hours in the admin, not in code, so the next city is a settings change.
4. Watch three numbers daily: time from order to delivery, orders per provider per online hour, and the share of orders needing support.
5. Open the next zone only when the first one's contribution per order is positive.

Unit economics: the number that decides everything

An on-demand business makes or loses money on each order. Revenue per order (commission, delivery fee, service fee) minus variable costs per order (provider pay, payment processing, refunds, support, the marketing it took to get the order) is the contribution. If it is negative, more orders mean bigger losses. Our on-demand app business models post works through a per-order table with labelled assumptions; use it before you set fees. The software can help: batching, better dispatch and fewer refunds all move the number.

Admin and operations tools

The admin is where your team spends the day, so it needs more than user lists. Build a live map of open orders and online providers, a timeline for each order (placed, accepted, ready, picked up, delivered) with every status change and who made it, one-click refunds and credits with reasons, provider document review and approval, merchant onboarding, zone and fee settings, and a support view that shows an order, the customer, the provider and the merchant on one screen. Log every manual action for audit. Teams that skip this end up running operations from database queries and spreadsheets within a month of launch.

Cancellations, late orders and refunds

Most support tickets come from the same few cases: the provider cancels after accepting, the merchant runs out of an item, the order is late, an item is missing. Write the rule for each before launch: who is charged, who is paid, whether the job is re-dispatched, and what the customer sees. Automate the common ones, such as a credit when delivery is more than a set number of minutes past the promised time, and route the rest to a person. Track the cost of refunds and credits per order; it belongs in the unit economics, not in a separate budget.

Own fleet or delivery-as-a-service

You do not have to build a courier network. DoorDash Drive and Uber Direct let a business send its own orders to their couriers through an API, and local courier companies offer the same. That changes the build and the business.

A practical path many founders take: launch with delivery-as-a-service in the first city, which removes the provider app and most of the dispatch work, then build your own fleet once order volume makes the per-delivery fee more expensive than running providers yourself. Design the order model so the delivery provider is a field, not an assumption.

Our relevant work

We have not built a food delivery or ride-hailing platform at national scale, and we will not pretend we have. The components are work we have shipped: Seek My Service is a service marketplace where verified vendors bid on local requests, with availability lookups by zip code, Stripe-funded vendor credits and SMS, email and in-app notifications. CareFlair is a two-sided marketplace with geospatial search on MongoDB 2dsphere indexes and real-time messaging on Socket.io. LogFish has live GPS tracking with Mapbox, Stripe payouts for professional users and offline-first mobile apps.

To scope a build, start with our on-demand app development page, or go straight to food delivery app development, grocery delivery app development or ride-sharing app development. Discovery with us costs $3k to $8k and ends with a fixed estimate.

Sources

• Innovation Insight app development cost calculator and pricing
• Stripe Connect documentation: https://docs.stripe.com/connect
• Google Maps Platform, Routes API: https://developers.google.com/maps/documentation/routes
• PostGIS documentation: https://postgis.net/documentation/
• Innovation Insight, Seek My Service, CareFlair and LogFish case studies