Donate to support freedom.
Get the same

On-Demand Service App Development

On-demand service app development: customer and provider apps on one backend, dispatch rules, live tracking, and an operator console for the exceptions.

On-Demand Service App Development

An on-demand platform looks finished the day a customer books a slot and watches a pin move toward their address. What decides whether the business holds together is the ninety minutes after the assigned driver cancels, the cleaner's phone loses signal in an underground car park, or the customer is not at the address they typed.

We build booking and dispatch products for service and delivery operators: a customer app, a provider app, one backend that owns the job record, and a console your office staff use when the automated path has stalled.

What an on-demand service app is

Two role-based clients share one job record. The customer app covers discovery, price, scheduling, live tracking, and payment. The provider app shows the offers sent to that person, lets them accept or decline inside a time window, provides navigation, collects status updates at each stage, and shows what they will be paid. Both read the same order, so a status change by the provider reaches the customer's screen within seconds.

Behind them sit the services that make a schedule real: matching rules, availability, location ingestion, notifications, a payments ledger, and ratings. The backend and cloud infrastructure is a large share of that work.

Who this is for

Operators who send a person or a vehicle to an address: home cleaning, repairs, beauty and wellness, courier and food delivery, car rental with delivery, and field service teams with a dispatcher in the office.

The parts repeat whether you employ your providers or onboard independent ones. When providers set their own capacity and prices, you are also building a marketplace platform.

Where the project starts

The scope of release one depends on what you already have.

A plain idea means we design the job model with you before any code. The first two weeks go on order states, matching rules, and the exceptions your dispatchers handle by phone today. This is the cheapest point to decide that a provider can hold three jobs at once, or that a cancellation inside two hours carries a fee.

An existing conventional codebase already encodes your real rules and customer data. We map its booking and pricing logic into the new job model and keep it running while the apps are built against it, the way the CBAY reservation flow and the Nubisreservation platform carry logic we can reuse.

An AI or vibe-coded prototype usually gets the demo right and the transitions wrong. The order state lives in one file, the payment authorisation is missing, and a declined offer has nowhere to go. We keep the sound parts and rebuild the job record before it reaches real customers.

What we deliver

Matching and dispatch

Dispatch is a rules engine with a visible queue behind it. Jobs go to providers chosen by distance, availability, skills, vehicle type, or rating, in waves: the nearest group, then a wider radius, then your office. Every offer, decline, timeout, and acceptance is stored with a timestamp, so you can see why a job took eleven minutes to fill.

Escalation belongs in release one. When the waves run out, the job lands in a dispatcher queue with the reason it failed, the providers who declined, and a manual assign action; the customer gets a revised estimate or the option to rebook. We instrument the queue so you learn which zones produce the most failures.

Live tracking that survives bad signal

The customer app shows a position, an arrival range, and the provider's name and vehicle. We treat the location stream as unreliable on purpose: readings are timestamped and batched, the map falls back to the last confirmed point with its age shown, and the estimate widens when data goes stale. That covers tunnels, basements, and phones that throttle background work.

The mapping, geofencing, and permission work sits with location and maps integration, including background location and the store review questions that follow.

Availability, scheduling, and money

Schedules are the part customers notice when they break. We model working hours, time off, recurring availability, service areas, travel buffers, and capacity per slot, so a provider who takes a two-hour job at 10:00 is not offered a job at 11:00.

A cancellation policy only works if the system can enforce it. We define who may cancel, at which stage, and with what fee, then route every case through one ledger: card authorisation at booking, capture on completion, and a no-show recorded with arrival time and location as evidence. Refunds and provider travel pay after a late cancellation run through payment gateway integration, where webhook replay protection keeps a capture or refund from being applied twice.

The operator console

Screens for your office staff carry the decisions the automation cannot take: reassign a job whose provider went silent, adjust a price, refund a fee, suspend a provider, and read the record of a disputed job. Ratings from completed jobs sit on the same record, and a provider whose completion rate slips loses reach in dispatch.

Console work often looks like internal tooling and gets cut from the first budget, which is the difference between a pilot that runs and a pilot your team routes around.

How the engagement runs

Most builds run in four phases across roughly ten to sixteen weeks, depending on how much exception handling you want in the first release.

Phase one takes two to three weeks and settles the job model, availability, dispatch rules, and the admin schema. Phase two covers the provider app and the backend it needs, deployed to a pilot group of your staff or trusted providers. Phase three adds the customer app, payments, notifications, and live tracking. Phase four covers the console, reporting, store submission, and location permissions.

We deploy from the second phase onward. A pilot with real providers in one zone teaches more about acceptance rates and arrival estimates than another month of internal testing.

What it costs

Work runs at our flat rate of $39 per hour. The pricing page explains hourly and fixed scope engagements, plus monthly capacity plans from $2,699 for teams that need steady delivery, and lists our mobile MVP typical order at $4,800 to $8,500 across four to six weeks for one app of 20 to 25 screens. A two-role on-demand product sits above that, because the provider app, dispatch, live tracking, payments, and the console each need their own build and test time.

What moves the number: how many provider types and service categories you support, whether dispatch is automated or dispatcher-led at launch, whether payment is captured on completion with no-show fees, and how much reporting operations expects. We scope release one and phase the rest in week counts.

Proof

CBAY Rent A Car needed online reservations for a rental fleet in Cyprus. We built the booking engine with pick-up and return logic, availability by vehicle category, and pricing rules on WooCommerce, which shows the location-dependent availability rules at the centre of dispatch in a system a small team operates daily.

Housekeeper World is a cleaning service platform with mobile booking, package selection, and a flow that mirrors how the company schedules its teams. It shows the two-sided discipline this service needs, keeping the customer path short while the operational handoff stays intact.

Nubisreservation is a reservation platform with iOS and Android apps, a Laravel and MySQL backend, and Stripe payments. It shows a multi-role booking product with payments in the same build, the shape an on-demand platform takes when several parties touch an order.

Related services

Next step

Tell us how a job moves through your business today, including the calls your dispatchers make when something goes wrong. We will say which parts belong in release one.

Contact us with your service list and coverage area, or run the outline through the Vasilkoff.info estimator for an early scope and budget range.