Courier Mobile App Development for Food Delivery
We develop mobile applications for courier delivery in restaurants. This is not a simplified version of the client app—it's a tool that works all day in poor network conditions, one-handed. We remove unnecessary actions so the courier doesn't waste time on extra taps. Our experience: 5+ years and 50+ projects in this niche. Every project starts with analyzing courier scenarios: how they open the app, where they are, which actions are most frequent. The result is an app that doesn't irritate even after 50 deliveries.
How to distinguish a courier app from a client app?
Minimum actions on the critical path. Accept order → confirm arrival at restaurant → pick up order → navigation → confirm delivery. That's five actions. Each is one large button, no nested menus.
The "current order" screen is always the first thing the courier sees when opening the app, without needing to navigate. We implement this via AutoRoute (Flutter) with state persistence: the app remembers the courier is in the middle of a delivery even if they minimized it for 20 minutes.
Offline mode. In basements, elevators, weak signal areas—connection drops. Delivery statuses must be cached locally (Hive or Drift) and synced when connection recovers. If the courier taps "Order delivered" without network, that action must not be lost.
Why is offline mode critical?
Loss of delivery status means non-payment to the courier and customer dissatisfaction. Our solution guarantees data is saved on the device and sent at the first opportunity. We use background sync with conflict resolution.
Geolocation and dispatching
Courier coordinates are sent to the server every 10-15 seconds during active delivery. On the server (Laravel + PostGIS) this enables: showing the courier's real position on the client map, building heat maps of zone load, calculating actual travel time for ML predictions.
On Android—foreground service with a persistent notification "Delivery active". On MIUI, One UI, and other custom shells, without this the app gets killed by the system after 10-15 minutes. This is not a device-specific quirk—it's an architectural requirement for courier apps.
Routing: integration with Yandex Navigator SDK or Google Maps SDK for turn-by-turn navigation directly in the app—no switching to an external navigator.
How are orders distributed: push or broadcast?
Two approaches:
Push-model: dispatcher or algorithm assigns an order to a specific courier → app receives push → courier accepts or declines. Simple implementation, suitable for small courier fleet.
Broadcast-model: order is "auctioned" among available couriers in radius—first to accept delivers. Requires WebSocket with "in bidding" state, timeout, and fallback to next courier. We implement via Laravel Broadcasting + Redis Pub/Sub.
| Characteristic | Push-model | Broadcast-model |
|---|---|---|
| Number of couriers | up to 10 | from 10 to 100+ |
| Ease of implementation | low | medium |
| Assignment speed | high | medium (competition) |
| Prioritization algorithm | not needed | PostGIS ST_Distance + rating |
Broadcast-model assigns orders 30% faster with a fleet of over 50 couriers.
For a restaurant with 5-10 couriers, push-model is enough. For an aggregator with hundreds of couriers—broadcast with distance-based prioritization algorithm.
Courier financial module
Earnings per shift, payout history, status—in the app. Cash payment: courier records cash received, system reflects debt to restaurant. Payouts via bank transfer on schedule or via SBP payments (Tinkoff Business API). SBP payments reduce commission to 0.7%.
Tech stack
Flutter 3.x + Bloc, Laravel 10 + WebSocket (Laravel Echo), PostgreSQL + PostGIS, FCM, Redis, Yandex MapKit or Google Maps SDK.
Process
- Requirements analysis and architecture design.
- Prototype development and UX approval.
- App and backend implementation.
- Testing on real devices.
- Deployment and staff training.
| Stage | Duration | Result |
|---|---|---|
| Analysis | 1-2 weeks | Technical specification and prototype |
| Development | 8-12 weeks | MVP app |
| Testing | 2-3 weeks | Bug report |
| Launch | 1 week | Release in stores |
What is included
- Analytics and UX/UI design focused on courier scenario
- App implementation on Flutter with offline mode
- Backend development on Laravel with PostGIS
- Integration with maps and payment systems
- Testing on real devices (including budget Android)
- Publishing to App Store and Google Play
- Courier training and post-launch support
Typical mistakes in development
- Not developing a courier app separately from the client app—they are tightly coupled by events but have fundamentally different UX requirements. Combining them in one Flutter repo (shared packages) is reasonable; making one UI is a bad idea.
- Not testing on budget Android in real conditions. Xiaomi Redmi 9 with MIUI 12, poor LTE in the city center—this configuration breaks.
Timeline
MVP of a courier app with geolocation, delivery statuses, and routing—from 12 to 18 weeks. In combination with a client app and restaurant panel—from 24 weeks.
Cost is calculated individually after requirements analysis. Contact us to evaluate your project—we guarantee transparency of timeline and budget.