On-demand app development company for delivery, mobility and service marketplaces

One skeleton, five verticals

Every on-demand product answers the same questions: who asked for what, who will fulfil it, where they are now, and who gets paid how much. What changes between verticals is the thing being moved and how tight the clock is. That difference decides the dispatch logic, which is the part generic "on-demand clone" pitches skip.

The three apps and the console

Dispatch and live tracking

Dispatch is where on-demand products win or lose. The first version should be simple rules you can explain to a provider on the phone; optimisation comes once you have data.

• Matching: providers' last known positions in PostGIS or H3 cells, filtered by status, skills and vehicle, ranked by distance or ETA. For home services, broadcast to the top few qualified providers instead of offering one at a time.
• Offers: each offer has a timeout (often 15 to 30 seconds for deliveries and rides), a re-offer rule and a fallback to manual assignment in the console.
• Tracking: providers' apps send location every few seconds while on a job and much less often when idle; the server pushes updates to the one customer who needs them over WebSockets, and never trusts the phone's view of job status.
• Recovery: phones lose signal mid-job. Every status change is an idempotent API call the app retries, and the server is the source of truth for who holds which job.
• Map costs: routing, geocoding and ETA calls are billed per request. We cache, throttle and choose between Google Maps Platform and Mapbox per feature.

Payments, commissions and payouts

Money moves between three parties, which makes payments a design topic rather than an integration. On Stripe Connect, the choices that matter are the connected account type (how much of onboarding and KYC Stripe handles for your providers) and the charge type: destination charges suit one provider per order; separate charges and transfers suit orders split across a store and a courier. We cover the trade-offs in Stripe Connect for marketplaces.

Apple's guideline 3.1.3(e) says services consumed outside the app must be paid with methods other than in-app purchase, so on-demand apps take cards through Stripe or a regional processor rather than Apple or Google billing. That keeps the store's commission off your orders.

Aggregator, own fleet or delivery as a service

Worker classification is a live legal question. In the EU, Directive (EU) 2024/2831 on platform work must be transposed into national law by 2 December 2026, with a presumption of employment and rules on algorithmic management; US states and cities have their own rules. We build the software so that either model works, and recommend local employment counsel before launch.

What to build first

The first release has one job: prove that customers in one area will order and that providers will accept and complete jobs at a price that leaves you a margin. Everything else waits.

1. Provider onboarding and the provider app, because an empty map loses customers on day one. Recruit and onboard providers before you open to customers.
2. The request or order flow with the price shown up front, and a status screen the customer trusts.
3. Simple dispatch rules plus a manual assignment screen in the console, so your team can rescue any job the rules miss.
4. Payment, commission and a weekly payout, with refunds handled by staff from the console.
5. Ratings, promotions, scheduled orders, batching and surge pricing come after the first few hundred completed jobs, when you have data to tune them.

Technology we use

How an on-demand project runs

1. Discovery (one to two weeks, $3k to $8k): launch area, fulfilment model, revenue model, provider onboarding rules, payment provider and the regulations that apply.
2. Design: customer and provider flows prototyped and tested with a few real providers, who catch problems office testing never does.
3. Build in two-week sprints, with dispatch and payments built first because every other feature depends on them.
4. Closed pilot with a few dozen providers and invited customers to tune timeouts, ETAs and fees on real streets.
5. Public launch and support, with a maintenance retainer of $1.5k to $8k per month, or the same engineers kept on as a dedicated team.

What an on-demand app costs

Our published bands are $15k to $45k for an MVP and $50k to $150k+ for a full product. The delivery and ride rows come from our app cost calculator; the on-demand app development guide explains where the hours go and on-demand business models compares how each model earns.

On-demand and marketplace work we have shipped

• Seek My Service: a service marketplace in production since December 2023 where clients post requests and verified vendors bid. It matches requests to vendors by subscription area, category and zip code, runs a Stripe credit economy, enforces five roles with route-level permission guards, and notifies every party through Twilio SMS, SendGrid email and in-app messages.
• CareFlair: an Australian NDIS marketplace connecting participants with support workers, with geospatial search on MongoDB 2dsphere indexes, real-time messaging on Socket.io, worker screening verification and four user roles. Built in 16 weeks to store release.
• LogFish: a React Native app with live GPS tracking on Mapbox, a guide-for-hire marketplace and Stripe payouts with earnings dashboards for professionals, on seven NestJS microservices.

We have not published a delivery or ride-hailing case study yet. The pieces above (matching, live location, messaging, multi-party payments, admin consoles) are the parts an on-demand MVP is assembled from, and the vertical pages explain what each vertical adds. Start with whichever is closest to your idea, or talk to us through a mobile app development scoping call.