On-Demand App Development: Dispatch, Location, and the Three-App Problem

An on-demand platform is three applications, not one. There is a customer app, a provider app for the driver, courier, or technician, and an operations console for the people who have to intervene when reality diverges from the plan. Founders brief the first, budget for the first, and discover the other two in month three.

That structure is why on-demand builds are among the most expensive categories in app development, and why the cheapest viable version of one looks nothing like the finished vision.

The three applications, and their relative weight

The customer app, roughly 25 to 30 percent of the build. Browse or request, place an order, pay, track, rate. It is the part everyone imagines and the smallest share of the work.

The provider app, roughly 30 to 35 percent. Availability toggling, job offers with accept and decline, navigation handoff, status progression, proof of completion, earnings visibility. It runs all day on a phone in a vehicle with unreliable connectivity, which makes it technically harder than the customer app despite having fewer screens.

The operations console, roughly 20 to 25 percent. Live view of jobs and providers, manual reassignment, cancellation and refund handling, provider onboarding and verification, dispute resolution, and reporting. This is the application that makes the business operable, and it is the one omitted from nearly every initial brief.

The remainder is the backend, dispatch logic, payments, and notifications, which serves all three.

Dispatch, which is the actual product

Matching demand to supply is where an on-demand platform either works or does not, and it is a genuine algorithmic problem rather than a lookup.

The decisions that have to be made explicitly: whether jobs are offered to the nearest provider, broadcast to several, or assigned outright. How long a provider has to respond before the offer moves on. What happens when nobody accepts. Whether batching multiple jobs is permitted. How scheduled jobs interact with immediate ones. And how to weight fairness across providers against efficiency for customers, which is a policy question with commercial consequences.

Start simpler than you think you need. A first version that offers a job to the nearest available provider with a thirty second window and escalates outward is enough to run a real operation, and it produces the data you need to design something better. Sophisticated optimisation built before you have real demand patterns is optimisation against assumptions.

Live location, which is the hardest engineering problem

Continuous location tracking on a provider phone is where on-demand apps break, and the causes are platform behaviour rather than code quality.

Background location restrictions. Both platforms restrict background location and require explicit justification for the permissions involved, with app store review scrutinising it. On Android, manufacturer battery optimisation may curtail background work regardless of correct implementation, and the behaviour differs by brand.

Battery consumption. A provider app that drains a phone by lunchtime gets closed. Location update frequency must adapt to context: frequent while en route, sparse while idle.

Connectivity gaps. Location and status updates must queue locally and sync when signal returns, and the customer-facing map has to degrade honestly rather than showing a stale position as though it were current.

Accuracy expectations. Urban GPS is imprecise, and customers watching a map interpret jitter as a driver going the wrong way. Snapping to roads and smoothing are presentation requirements rather than nice touches.

‍

‍

Bolder Apps builds cross-platform mobile in Flutter and FlutterFlow and native in Swift and Kotlin, and this is one of the categories where the native module question is worth asking directly. Location and background behaviour is exactly the boundary where a cross-platform app needs platform-specific code, and a partner should be able to tell you which parts of the provider app they expect to write natively.

The number that decides an on-demand platform’s viability is not order volume. It is provider utilisation. A platform with too many providers per order loses providers to boredom; too few and customers wait. Launch narrowly enough geographically that both sides stay dense.

Money movement

On-demand platforms take payment from customers and pay providers, which makes them marketplaces with the accompanying obligations.

The specifics: authorising at order time and capturing at completion, since the final amount frequently differs from the estimate. Tips added after completion. Commission calculation and provider earnings, exact and reproducible. Payout scheduling with provider onboarding for identity verification and tax reporting. Cancellation policy with partial charges. Refunds that correctly unwind a split even when the provider has already been paid.

Use a payment provider’s marketplace facilities rather than building this. And keep an append-only ledger with balances derived rather than stored, integer minor units rather than floating point, and idempotency on every write, because provider earnings disputes are the fastest way to lose supply.

Cost and timeline

The first row is the one worth serious consideration. A booking product with an operations console and manual dispatch, where a coordinator assigns jobs, validates the business model at a fraction of the cost of an automated platform. Bolder Apps quotes MVP engagements at 8 to 20 weeks and prices project work fixed-scope, and a manually dispatched first version fits that window where a full three-app platform does not.

Notifications and communication, which carry the experience

On-demand products are largely experienced through notifications rather than through screens. A customer opens the app to order and then waits, and everything between order and arrival happens in the notification tray.

That makes push reliability a core requirement rather than an integration detail. On the provider side, a missed job offer notification is lost revenue for the provider and a delayed order for the customer, and both platforms’ background restrictions bear directly on whether that notification arrives promptly. Design for the case where it does not: an in-app job queue the provider can check, plus audible alerting while the app is foregrounded.

On the customer side, the sequence matters. Order confirmed, provider assigned, provider en route, arriving, completed. Too few updates and the customer opens the app repeatedly to check; too many and they mute you, which then loses you the one that mattered.

Communication between the two parties needs its own design. Direct phone numbers should be masked through a proxy, both for privacy and because providers change. In-app messaging with a fallback to a masked call covers most cases, and every channel needs a record for dispute resolution.

Bolder Apps builds cross-platform in Flutter and FlutterFlow, native in Swift and Kotlin, and backends in Laravel, Yii2, and Node.js, and prices project work fixed-scope rather than hourly. On on-demand work the scope items worth naming explicitly in a proposal are the operations console, the notification sequence, and background location handling, because all three are load-bearing and none of them appear in a wireframe.

Sequencing an on-demand build

Phase one: the customer app plus the operations console, with dispatch performed by a human and providers coordinated by phone or messaging. This proves demand, reveals the real dispatch rules, and is genuinely operable in one city.

Phase two: the provider app, replacing the phone calls once provider count makes manual coordination impractical, typically somewhere past fifteen to twenty active providers.

‍

‍

Phase three: automated dispatch, designed from the patterns phase one and two produced rather than from assumptions.

Phase four: expansion, multi-city, scheduled jobs, batching, and whatever the data has shown to matter.

Nearly every successful on-demand company ran a version of phase one manually for longer than its origin story suggests. It is the cheapest way to learn the operational rules that the software then encodes.

Operational realities that shape the software

Three things worth designing for because they will happen daily.

Providers cancel after accepting. Your dispatch logic needs reassignment that does not restart the customer’s wait from zero.

Customers are not where they said. Address correction mid-job, contact between parties without exposing phone numbers, and a defined policy for failed delivery or arrival.

Estimates are wrong. Travel time, service duration, and preparation time are all estimates, and customers judge you on the gap between promise and reality. Conservative estimates with honest updates outperform optimistic ones consistently.

Sources

• Apple documentation on Core Location background modes and permission requirements, developer.apple.com
• Android developer documentation on background location and battery restrictions, developer.android.com
• Google Maps Platform documentation on routes, distance matrix, and road snapping
• Stripe Connect documentation on marketplace payments and payouts, stripe.com/docs/connect
• US Department of Labor guidance on worker classification, dol.gov