An on-demand app that matches fast
and still lets a provider say no
On-demand only works if the match happens in minutes, not hours, and if the provider side has real control over what they accept. We build the routing and provider-acceptance logic first, the part that decides whether the whole model works, and the request screens second.
What it is and who needs it
An on-demand services app connects someone who needs a service done now, or soon, with a provider who can do it, handling the request, the match, the job itself and payment, usually within one session. It is for a platform building its own two-sided marketplace for home services, personal services, field repairs, or anything where speed of matching is the actual product, rather than relying on calls and messages to coordinate.
The part that decides whether this model works is never the request screen, it is whether a match happens fast enough and whether the provider side has enough control to keep showing up. We build around that from the first week.
What is inside
The client app covers requesting a service, seeing real matches rather than a generic “searching” spinner, tracking status, and paying in-app. The provider app covers accepting or declining jobs, seeing earnings, and managing availability, with real control to decline a job that does not fit, because a platform that strips that control burns out its supply side fast.
Matching and routing run on logic you control, round-robin, rating-weighted or zone-based depending on what fits your market, with both apps reading from one real-time job state so neither side ever shows a status the other has already moved past. Payments run in-app with payout splitting to providers built in, and the admin dashboard gives visibility into active jobs, provider performance and disputes as they happen, not after a complaint.
We also build in the operational detail that keeps both sides of the marketplace healthy over time: a rating system for both client and provider so accountability runs both directions, a cancellation policy with fair, enforced rules rather than an ad hoc decision every time, and a surge or availability signal so clients see realistic wait times instead of a request that silently sits unmatched. Provider earnings and payout schedules are visible in real time inside the provider app, because a supply side that cannot see what it is owed stops trusting the platform fast, and trust is the entire product here.
How we build it
- Map how matching actually needs to work. Round-robin, rating-weighted or zone-based, chosen for your market, not a default.
- Build the shared job state first. Both apps reading from one real-time state is what prevents the client-provider status gap that breaks trust in this model.
- Protect provider control. Accept or decline logic with a real fallback, built in from the start, not patched in after providers start leaving.
- Add payments with payout splitting. In-app payment that settles correctly between platform and provider from the first transaction.
- Launch with dispute visibility. An admin view into active jobs and provider performance so issues surface before they become churn.
Timeline and price
| Tier | Price | What’s included | Timeline |
|---|---|---|---|
| MVP | from $11,000 | Client app, provider app, basic routing, real-time job status | 10 to 16 weeks |
| Production | from $19,000 | MVP plus in-app payments with payout splitting, rating-weighted matching, admin dashboard | 16 to 20 weeks |
| Full control, handover-ready | from $32,300 | Everything in Production plus full handover documentation for your own team | 16 to 20 weeks |
What you own at the end
Both app codebases, the job and routing data, and the matching rules, all under your own infrastructure and accounts. Payment processing runs through your own provider account, and the routing logic is documented well enough for your own team to tune it without us.
Related
See the development service page for our general build process, and the delivery and courier app and taxi and ride app pages for related two-sided builds. For infrastructure, see booking engine for services and split payments and payouts. For the real routing numbers behind this model, see the real estate lead routing case in Bali and the visa centre’s bots with hand-off to a human.
Building a two-sided service platform and not sure your matching logic will actually hold up? Get in touch and we will map it with you before writing code.
FAQ
How much does an on-demand services app cost?
From $11,000 for a client app, a provider app, and routing logic with real-time job status. In-app payments with payout splitting and rating-weighted matching typically add $4,000 to $7,000.
How long does it take?
10 to 16 weeks for both apps and the shared routing and job-state logic, since getting that part right before either UI is finished is what makes the model actually work.
What stack handles matching and real-time job status?
React Native and Expo for both apps, a FastAPI or Node backend owning job state and routing rules, PostgreSQL for jobs and providers, and Redis for the fast-moving presence and availability data.
Who owns the matching logic and the data?
You. Routing rules, job history and provider data live under your own infrastructure, and both app codebases are yours. There is no dependency on a third-party gig platform unless you choose to integrate one.
Can providers really decline a job, or is it forced?
Providers can decline, and the routing logic accounts for that with a fallback to the next best match. A platform that forces acceptance burns out its supply side quickly; we build provider control in from the start because it is what keeps a supply side willing to keep showing up.