Industries: on-demand services
On-demand services app development for two-sided marketplaces
On-demand services app development is mostly marketplace engineering: two user groups with opposite incentives, money that must land in the right account, and a map that has to stay accurate. We build customer apps, provider apps and admin panels for home services, ride-hailing, delivery and booking businesses selling in the USA, UK, UAE/GCC, Europe and Australia.
This page covers the sector-level decisions: provider vetting, scheduling, live tracking, payments and payouts, and the rules that apply in each market. It sits under our overview of industries we build apps for; for a single app type, jump to the solution pages below.
- Customer, provider and admin apps planned as one system
- Payment flow mapped in discovery, before design
- NDA before discovery; you own code and store accounts
- Reply within one business day
Why on-demand apps struggle (it is rarely the UI)
A marketplace with customers but no providers in their postcode is a broken product, however polished the screens. Most on-demand businesses should launch in one city or category, with the admin panel doing manual matching until volume justifies automatic dispatch.
Trust has to work in both directions. Customers let a stranger into their home or car; providers travel to an address with no guarantee of payment. Vetting, ratings, deposits and cancellation fees are product features, not policy pages, and they need screens, states and admin tools.
The money flow is the most expensive thing to get wrong. Charging, holding funds, paying the provider minus commission, tips, partial refunds and disputes each touch accounting, tax and support. Changing the flow after launch means migrating live balances.
Then there is location: GPS drifts indoors, phones kill background apps, and ETAs built on bad data become support tickets.
On-demand app types we build
Each of these is a suite rather than a single app: usually a customer app, a provider or driver app and a web admin panel sharing one backend.
Home services marketplaces
Cleaners, plumbers, electricians and beauty at home. Fixed-price or quote-based booking, time slots, provider skills and service areas, and photo notes before and after the job.
Taxi and ride-hailing
Rider app, driver app and dispatch panel with fare rules, zones and live trip tracking. In London, the business also needs a TfL private hire operator licence before it accepts bookings.
Food delivery
Three-sided: customer, restaurant and rider. Prep-time estimates, order batching and rider assignment are where most of the engineering effort goes.
Grocery and quick commerce
Delivery slots with capacity limits, substitutions, store picker apps and partial refunds.
Multi-vendor service marketplaces
Many businesses selling bookable services under one brand, with vendor onboarding, per-vendor commissions, vendor dashboards and scheduled payouts.
Appointment and booking apps
Salons, tutors and clinics: calendar sync, deposits, no-show rules and reminders. Clinic bookings add health-data rules, covered on our doctor appointment booking app development page.
Provider vetting, scheduling, tracking and payouts
Provider vetting and onboarding
Providers upload ID, licences and insurance in the app; an identity-verification vendor runs document and selfie checks; a background-check provider runs checks in markets where they are permitted. Everything lands in an admin review queue with rejection reasons and expiry reminders. Store only what you need: these documents are personal data under GDPR and UK GDPR.
Scheduling
Decide early whether you sell instant jobs, scheduled slots or both. Scheduled work needs provider calendars, travel buffers, slot capacity and time-zone handling. Double bookings are prevented by locking on the server, never by checks in the app.
Live tracking
The provider app shares location only while a job is active, throttled by speed and distance to save battery. Updates reach the customer through realtime listeners such as Cloud Firestore or a WebSocket service, and ETAs are shown as ranges. Both platforms treat background location as sensitive, so the job flow must still work when a provider grants only “While Using” access.
Payments and payouts
Services consumed outside the app cannot use in-app purchase or Play billing, so bookings run through a payment provider with marketplace features: split payments, held funds, provider onboarding and scheduled payouts. Our payment gateway integration page compares the options.
Compliance for on-demand services app development in the US, UK, EU and UAE
These rules come up on almost every marketplace we scope. They decide screens, data retention and payment architecture, so we design to them in discovery.
| Market | Rule | What it means for your app |
|---|---|---|
| All stores | Apple Guideline 1.2 (user-generated content) | Reviews, chat and provider profiles need a content filter, a way to report, the ability to block users and published contact details. |
| All stores | Apple 5.1.1(v) account deletion | Customers and providers can delete their accounts in the app. Keep only the records you must retain for tax or disputes. |
| USA (California) | CCPA as amended by CPRA (from 1 Jan 2023) | Applies above $25M revenue, or to businesses buying, selling or sharing data of 100,000+ California consumers or households, or earning 50%+ of revenue from selling data. Users can know, delete, correct and opt out, including via Global Privacy Control. |
| UK | UK GDPR and DPA 2018 | Location history and ID documents are personal data. Maximum fines reach £17.5M or 4% of worldwide turnover. |
| EU | GDPR, PSD2 Strong Customer Authentication, European Accessibility Act | Card payments need SCA (3-D Secure in checkout). The EAA applies from 28 June 2025; Dutch government guidance lists marketplaces and meal booking platforms as e-commerce, and transport services including apps are covered. |
| UAE | Federal PDPL (effective 2 Jan 2022); DIFC Data Protection Law 2020 | The PDPL reaches non-UAE companies processing UAE residents’ data, but not DIFC or ADGM, which have their own regimes. DIFC fines run US$25,000–100,000 per infringement. |
General information, not legal advice; confirm with your lawyer for your entity and markets. Sources: Apple App Review Guidelines, Google Play payments policy, ICO fining guidance.
Integrations common in on-demand apps
Most of an on-demand backend is glue between specialist services, chosen by market and volume.
| Integration | Typical options | Watch out for |
|---|---|---|
| Maps, geocoding, routing | Google Maps Platform, Mapbox | Usage billing grows with tracking frequency; cache geocodes and throttle updates. |
| Payments and payouts | Stripe Connect, Adyen, Checkout.com; JazzCash or Easypaisa for Pakistan | Provider identity checks before the first payout; refunds after a payout has already gone out. |
| Push and SMS | Firebase Cloud Messaging, APNs, Twilio | Keep transactional and marketing messages separate, with their own opt-ins. |
| Masked calling and chat | Twilio number masking, Stream, Firebase | Chat counts as user-generated content under Apple 1.2. |
Security practices for marketplace apps
Marketplaces attract fake providers, promo abuse and account takeovers. These controls are in scope from the first sprint.
- Card data is tokenised by the payment provider’s SDK, which usually keeps you in the lowest PCI DSS self-assessment tier (SAQ A), though it does not make you compliant by default.
- Every job state change is authorised on the server: a provider can only accept, start or complete their own jobs.
- Location is collected only during active jobs, with a written retention window for trip history.
- Provider documents sit in private storage with short-lived signed URLs, encryption at rest and access logging.
- Admin roles split support, finance and super-admin, with an audit log of refunds and payout changes.
- Testing against OWASP MASVS before launch, plus Apple privacy manifests for listed third-party SDKs (required since 1 May 2024).
Feature map: customer app, provider app and admin panel
A typical v1 split. The admin panel is often underestimated; our admin panel and dashboard development page explains why it deserves its own design work.
| Area | Customer app | Provider app | Admin panel |
|---|---|---|---|
| Onboarding | Phone, email or social sign-in | Documents, skills, service area, payout details | Approve or reject, document expiry tracking |
| Booking | Instant or scheduled, price estimate, saved addresses | Accept or decline, availability calendar | Manual assignment and overrides |
| Tracking | Live ETA and status updates | Navigation hand-off, location sharing during jobs | Live map of active jobs |
| Payments | Cards, wallets, tips, receipts | Earnings, payout history | Commissions, refunds, disputes |
| Trust | Ratings, reports, help centre | Rate customers, report issues | Moderation queue, bans |
| Growth | Promo codes, referrals | Incentives and bonuses | Campaign rules and reports |
Scope your marketplace before you ask for a price
Answer these before any estimate. Each one moves the effort range more than screen count does.
- Instant jobs, scheduled slots or both? Scheduled work adds provider calendars, travel buffers and slot capacity.
- Fixed price, quote-based or metered (per hour, per mile)? Quotes add a negotiation flow and an approval step.
- Who holds the money and when: charge at booking, authorise and capture on completion, or deposit plus balance?
- How providers are paid: per job, weekly batch or on demand, and in which currencies and countries.
- Which vetting checks the law in each launch market allows, and which vendor runs them.
- How much of dispatch stays manual in the admin panel for the first city.
- Then put those answers into the app cost calculator for a typical effort range. For ride-hailing, the cost to build an app like Uber shows where the hours go; for services, see on-demand app development cost.
How we de-risk on-demand projects
Our standard process, with the marketplace checks made explicit.
Discovery: map the money first
One to two weeks of workshops after the NDA is signed. We draw who pays, when funds are held, who gets paid and how refunds work, then choose a payment provider that supports your entity and markets. A fixed price follows discovery.
Scope one city, one category
The first release does manual matching in the admin panel and automates later. A focused MVP app development build usually takes 8–16 weeks after discovery.
Pick a stack that fits two apps
Customer and provider apps often share a Flutter or React Native codebase, with a Node.js or Laravel API and Firebase or WebSockets for realtime updates. We go native where background location or hardware access demands it.
Two-week sprints with field testing
Every sprint ends with a demo build on TestFlight and Play internal testing, tested by providers on low-end Android phones and mobile data.
Break the payments on purpose
Before launch we run refunds, failed payouts, expired cards and disputes end to end in the payment sandbox.
Prepare both apps for review
Demo accounts for customer and provider apps, reviewer notes on location use and on why payments do not use in-app purchase. Our mobile app launch checklist covers the rest.
On-demand app development: frequently asked questions
How much does an on-demand services app cost?
It depends on how many apps are in the suite (usually three), how much is realtime, and how complex payouts are. As market data, Clutch’s app development cost guide (updated September 2026) reports that most projects reviewed on its platform fall between $10,000 and $49,999, with an average of $90,780. Marketplaces tend to sit above simple apps because of the provider app and admin panel. A fixed price follows discovery.
Should customers and providers use one app or two?
Two apps is usually cleaner. Providers need background location, earnings and document screens customers never see, and separate apps keep store listings and permissions focused. One app with a role switch can work when the same people act as both buyer and seller, as on some peer-to-peer marketplaces, but it complicates permissions and App Review notes.
Can we take bookings through Apple in-app purchase?
No. Apple’s Guideline 3.1.3(e) says goods and services consumed outside the app must use payment methods other than in-app purchase, and Google Play’s payments policy says Play billing must not be used for physical services. A cleaning visit, ride or delivery is paid through a payment provider such as Stripe, Adyen or a local gateway, with Apple Pay and Google Pay as checkout options.
Can a business registered in Pakistan use Stripe?
Stripe’s global availability page lists 51 countries and Pakistan is not among them, while the US, UK and UAE are. Founders selling abroad often operate through an entity in their target market. For a Pakistan-only marketplace, JazzCash and Easypaisa both offer online payment gateways that support mobile apps. We confirm the choice with your accountant during discovery.
Do you sell ready-made clone scripts?
No. Apple’s Guideline 4.3(b) targets apps indistinguishable from what is already widely available, so template clones carry real rejection risk, and resold scripts often come with licensing limits on the code. We build your apps in your own repository, reusing proven patterns for booking, tracking and payouts, so you own everything and can change the business model later.
How do we stop customers and providers going off-platform?
Make staying on the platform worth more than leaving it. Masked calls and in-app chat hide phone numbers, while payment protection, guarantees and easy rebooking with the same provider give both sides a reason to stay. Some leakage is unavoidable, so the admin panel should flag repeated cancellations.
Plan your on-demand marketplace with us
Tell us the service, the first city and how providers should be paid. We reply within one business day (Pakistan time) with questions and next steps, and we sign the NDA before discovery starts.