Last-Mile Delivery App Architecture: 5 Patterns We've Shipped
Last-mile delivery looks simple from the outside. From the inside, it's a meeting of offline-first mobile, real-time backend, payment reconciliation, and human operations. Here are 5 patterns we've shipped that work.
Key takeaways
- Offline-first is non-negotiable: drivers lose connectivity constantly.
- Route optimization runs server-side; driver app receives ordered list.
- OTP-based delivery confirmation is now standard.
- COD reconciliation needs its own dedicated flow.
- Real-time tracking requires both push (driver app sending GPS) and pull (customer querying status).
Pattern 1: Offline-first driver app
Driver apps must work without network. Architecture:
- Local SQLite database holds today's deliveries
- Sync to server when network available
- Conflict resolution: server is source of truth; driver mutations queued for replay
- Pre-download maps for driver's area to avoid online map dependency
Without this, drivers in rural areas (most of India) can't work.
Pattern 2: Route optimization, sent as ordered list
Drivers don't run optimization on their phone. Server-side optimization (algorithms like VRP or services like Google Routes API) produces an ordered list of stops. Driver app shows that list with current next-stop highlighted.
Re-optimization on real-time events (delivery cancelled, traffic) triggers a fresh list.
Pattern 3: OTP-based delivery confirmation
Customer receives OTP via SMS. Driver enters OTP at delivery. Confirms identity and presence. Reduces wrong-delivery fraud.
Backend validates OTP via SMS provider; logs every attempt.
Pattern 4: COD (Cash on Delivery) reconciliation
Driver collects cash. End of shift, deposits to hub. Hub deposits to bank. Each step logged.
App-level reconciliation:
- Driver-side: shipments with COD due, total collected today
- Hub-side: drivers who've deposited, drivers who haven't
- Bank-side: deposit amounts received
Discrepancies surface immediately. Without explicit reconciliation, cash disappears.
Pattern 5: Real-time tracking with bounded fidelity
Customer wants to know "where's my order." Driver app pings GPS to server every ~60 seconds. Backend serves customer "current driver location" with reasonable fidelity (don't share precise location to protect driver privacy).
Backend pattern: time-series store of locations; latest location served to customer with timestamp.
Common pitfalls
Sync conflict bugs. Driver marks delivered offline; concurrently it's cancelled by dispatcher. Server wins.
Battery drain from GPS. Aggressive GPS polling kills phones. Tune.
Customer location not used. Apps that don't show ETA + driver location feel old.
No exception flows. "Customer not home" needs explicit workflow with photo evidence.
What works for driver UX
- Big tap targets (drivers use one hand)
- Voice navigation handoff (let drivers use Google Maps for navigation)
- One-tap status updates ("Delivered", "Customer not home", "Address issue")
- Photo upload for delivery proof
What we recommend
React Native for cross-platform driver apps usually wins (one codebase, faster shipping). Native for very high-volume operations.
FAQs
Maps choice? Google Maps for navigation; OSM/Mapbox to save costs on tracking display.
Offline maps? Pre-download driver's territory.
Multiple language support? Essential. Drivers come from diverse regions.