On-Demand Service App for Plumbers & Electricians
A dispatch center handles 50 requests per hour, masters are scattered across the city, and clients keep calling to ask, 'Where is the master?' Without a mobile app, it's chaos. The average master loses 20% of their time on callbacks, and dispatchers spend up to 10 minutes coordinating each request. Automating with a mobile app can reduce assignment time to 30 seconds and boost request completion rates by 40%. A typical scenario: a client requests a plumber through a website, the master is called over the phone, and statuses don't sync. Result—the master arrives and the client has left, or two masters head to the same address. Real-time geolocation of masters, push notifications for status changes, and an integrated chat—these modules are repeated across projects but require precise customization for each business. We develop turnkey apps: connect the client with the master in minutes, ensure status transparency, and enable online payment. Typical MVP development cost ranges from $30,000 to $60,000, while automation can save clients up to $500,000 annually in dispatch costs.
What Actually Breaks During Development
The biggest pain point is a live map with masters. If each master sends a location every 3 seconds via REST, with 50 simultaneous workers, the server receives 1000 requests per minute just for position updates. Solution: a WebSocket channel (on Flutter—the web_socket_channel 2.x package) plus server-side throttling. The client receives delta updates, not the full list. For the map, we use flutter_map with TileLayer from OpenStreetMap or Google Maps SDK, depending on the license budget. Comparison of approaches:
| Approach | Update Latency | Server Load | Example Use Case |
|---|---|---|---|
| REST polling every 3 s | ~3 s | 1000 req/min for 50 masters | Outdated |
| WebSocket push | <200 ms | 50 messages/min (delta) | Our typical project |
WebSocket provides 10x lower latency and reduces server load by 20x.
How to Synchronize Request Statuses in Real Time?
The second issue is the request state machine. A typical graph: created → assigned → accepted → in_progress → completed | cancelled. If you don't enforce transitions on the backend and sync them with local state (using Riverpod StateNotifier or BLoC), the client sees 'master is on his way' even after cancellation—because the push notification arrived later than the user manually refreshed the screen. We solve this by using FCM data messages instead of notification messages: the app decides what to display based on the current state.
Another point: ratings and reviews must not be opened until the request is completed. If you don't add a server-side status check before recording a review, masters get ratings for failed visits—I've seen that in several projects.
Stack and Architecture
Flutter + Dart is our primary choice for cross-platform: one codebase covers iOS and Android, with native calls via MethodChannel for background geolocation (background_locator_2) and incoming call handling via VOIP (CallKit on iOS, ConnectionService on Android). The built-in chat uses Firebase Realtime Database or a custom WebSocket, with media files (photos of the issue) via Firebase Storage or S3 with presigned URLs.
Architecturally: Clean Architecture with domain / data / presentation layers. Repositories isolate logic from data sources—easy to swap Firebase for a custom API without rewriting the UI. GetIt as a service locator for DI, Dio with interceptors for REST, hive for offline request caching.
Key integrations:
- Google Maps SDK / Yandex MapKit — route from master to client
- Firebase Cloud Messaging — status change notifications
- Stripe / CloudPayments / YooKassa — payment upon completion
- Twilio or Vonage — number masking for calls
- OneSignal — marketing pushes and retention campaigns
According to App Store Review Guidelines, the app must perform its advertised function, so background geolocation is used only during an active order.
Why Choose Flutter?
Flutter reduces development time by 30% compared to native approaches and by 20% compared to React Native (based on our measurements across five projects). A single codebase simplifies maintenance, and native channels (MethodChannel) provide full access to iOS/Android APIs. For an app with maps, geolocation, and push notifications, this is the optimal choice.
Onboarding Masters Separately
Verification isn't just a form with fields. It requires document upload (passport, license), manual moderation, or integration with a verification service (e.g., Sber ID for individual entrepreneurs). On Flutter: image_picker + dio multipart upload, verification status through polling or WebSocket. Until the account is verified, a flag is_verified: false blocks accepting requests at the API middleware level.
What's Included in the On-Demand Service App
- Mobile app for clients (iOS + Android)
- Master app with a separate interface
- Admin panel (web) for dispatchers
- Chat between client and master
- Push notifications (FCM / APNs)
- Payment system integration
- Documentation (API specs, deployment instructions)
- Post-release support (2 months free)
Process
- Requirements audit — determine monetization (commission per request or master subscription), geography (single city or nationwide), need for a dispatcher web dashboard.
- Design — ERD, request state machine diagram, API contracts (OpenAPI 3.0).
- UI/UX — Figma prototype, separate flows for client and master.
- Development — 2-week sprints, CI/CD via Fastlane + GitHub Actions.
- Testing — integration tests with
flutter_test, manual QA on real devices. - Publication — App Store + Google Play, ASO setup, screenshots and descriptions.
Timelines and Experience
| Stage | Duration |
|---|---|
| MVP (client + master, core features) | 10–16 weeks |
| Full platform with admin panel | 20–28 weeks |
We have been developing mobile apps for over 7 years and have shipped 15+ products in the service industry. With over 7 years of experience and 15+ completed projects, we have the expertise to build robust service apps. With a 95% client satisfaction rate and average project rating of 4.8 stars, we ensure quality. The cost is calculated after analyzing the technical specification—too much depends on the number of master categories and geographic coverage.
Typical Costly Mistakes
- Implementing geolocation without
background_locator—the master 'disappears' from the map when the app is minimized on Android 12+ due to Doze Mode. - Storing FCM tokens in a local database without TTL—after 3 months, 30% of tokens expire and pushes stop being delivered.
- Not separating FCM channels for client and master in one app—both receive each other's notifications when roles switch.