Courier and Last-Mile Delivery App Development

Engineering teams building last-mile delivery platforms deal with problems that compound at scale: order dispatch across hundreds of concurrent couriers, real-time position tracking with sub-10-second freshness, route optimisation under time-window constraints, and proof-of-delivery workflows that hold up in disputes. Scrums.com builds dedicated teams around your courier domain: engineers who design order intake pipelines, dispatch scoring engines, driver tracking infrastructure, and delivery SLA monitoring. Every system is built for operators managing fleets and fulfilling merchant SLAs.

Order Intake and Dispatch Architecture

Delivery orders enter through an intake API that validates, geocodes, and persists in a single atomic write. The delivery_orders table stores canonical order state: order_id, sender, recipient address, package dimensions and weight, service level (STANDARD, EXPRESS, SAME_DAY), pickup window, delivery window, and current status. Address validation runs on intake: a geocoding call (self-hosted Pelias or Google Maps) resolves each address to a normalised form plus (lat, lng) with a geocode_confidence_score. Low-confidence addresses are queued for dispatcher review before assignment.

Order status follows an append-only state machine: CREATED / PICKUP_ASSIGNED / PICKED_UP / IN_TRANSIT / OUT_FOR_DELIVERY / DELIVERED | FAILED | RETURNED. Every transition writes to order_events with actor, location point, timestamp, and notes. The current status is derived from the latest event, no status field is overwritten. The dispatch engine scores couriers against each new order using: proximity to pickup (PostGIS ST_Distance), courier capacity vs package dimensions, SLA deadline urgency, and current active load. A manual_override_log records dispatcher interventions with reason_code for audit and model improvement. Zone-based batch dispatch clusters orders by geohash to minimise courier repositioning between pickups.

Real-Time Driver Tracking and Route Optimisation

Courier positions stream from a mobile SDK heartbeat at 10-second intervals into a courier_positions append-only table: courier_id, latitude, longitude, timestamp, accuracy in metres, and battery percentage. A courier_current_location materialised view refreshes from the latest position per courier and is the source for all dispatcher map UIs and proximity queries. PostGIS handles spatial lookups: nearest available couriers to a new order, coverage zone membership, and geo-fence compliance checks for restricted delivery zones.

Multi-drop route planning uses OR-Tools VRPTW (Vehicle Routing with Time Windows). An optimisation_job record captures algorithm, parameters, status, and the resulting route_plan_json with ordered stops, total distance, and estimated duration. Each stop carries an (earliest_arrival, latest_arrival) time window; the solver minimises total distance while penalising window violations. OSRM provides turn-by-turn routing for each leg. ETA is recalculated at every stop completion and re-pushed to the customer if the new estimate deviates more than five minutes from the previous one. Route reoptimisation triggers automatically on: new urgent order insertion, stop failure, or significant traffic delay flagged by the traffic feed.

Courier and last-mile delivery apps like these are built and delivered by dedicated engineering teams through our mobile app development service.

Proof of Delivery and Failed Delivery Workflow

Proof of delivery is a legal record and a dispute resolution asset. The proof_of_delivery table stores: pod_id, order_id, delivered_at, delivery type (SIGNATURE, PHOTO, PIN, LEFT_IN_SAFE_PLACE), image URLs for signature or photo, recipient name, and the GPS point at delivery. Geo-validation runs on submission: the delivery event must occur within a configurable radius of the delivery address (default 50 metres); events outside this range are flagged to a review queue rather than silently accepted.

Signature images and delivery photos are captured via the mobile SDK, stored immediately to object storage (S3 or GCS), and only the URL is written to the database. Raw binary data never lands in the application database. Failed deliveries write a failed_delivery_reason from a typed enum: NOT_HOME, ADDRESS_NOT_FOUND, REFUSED, ACCESS_RESTRICTED, DAMAGED. A redelivery workflow pushes failed orders into a rescheduling queue with a configurable attempt limit (default three); after the limit the order automatically transitions to RETURN_TO_SENDER and a reverse logistics route is generated.

Dispute resolution uses a dispute_log table: order_id, raised_by, evidence URLs, resolution notes, and resolved_at. SLA breach events are written when delivered_at exceeds the promised delivery window; these feed directly into a sla_compliance_report view used for carrier performance reviews and customer credit calculations.

Delivery Analytics, Notifications, and Merchant Integrations

Operational analytics are built as materialised views over append-only event tables; no aggregation logic lives in application code. The delivery_kpis view surfaces on-time delivery rate, first-attempt success rate, average delivery time by zone, and cost per delivery. A courier_performance view computes deliveries per hour, failed delivery rate, average customer rating, and SLA compliance percentage per courier, refreshed nightly by a scheduled dbt job for reporting and by a 15-minute micro-batch for operational dashboards.

Zone-level heatmaps are built from delivery_density queries over geohash cells, used by capacity planners to adjust courier allocation by area and time of day. Customer notifications are event-driven: order_events publish to a notification router that dispatches via FCM (Android), APNs (iOS), SMS, or email depending on channel preference stored in the customer profile. Templates are locale-aware and managed in a notification_templates table rather than hardcoded in application logic.

Merchant integrations use outbound webhooks with HMAC-SHA256 request signing and a configurable retry policy with exponential backoff. An integration_log records every delivery event and its dispatch status for debugging and SLA reporting. E-commerce connectors pull orders from Shopify and WooCommerce via REST and push status updates back on each state transition. Returns management creates a return_order from any failed delivery, routes it to the nearest depot, and synchronises the return status back to the merchant system.

Frequently Asked Questions

What does it take to build a last-mile delivery platform from scratch?

You need backend engineers who can design append-only event systems, geospatial databases (PostGIS), and real-time data pipelines. Mobile engineers build the courier app in Kotlin (Android) and Swift (iOS). A route optimisation specialist configures the VRPTW solver. Scrums.com assembles dedicated teams with all these skills so you are not hiring individually across multiple disciplines.

How does the dispatch engine assign couriers to new orders?

The dispatch engine scores available couriers using a weighted function: proximity to the pickup point (PostGIS spatial query), courier capacity vs package dimensions, SLA deadline urgency, and current active order count. Weights are stored in a dispatch_config table so operators can tune assignment logic without a code deployment. All dispatcher overrides are logged with a reason code for audit and model improvement.

How do you prevent proof-of-delivery fraud?

Delivery events are geo-validated against the recipient address: events submitted from outside a configurable radius (default 50 metres) are flagged for review rather than accepted. Signature and photo captures are timestamped, geo-tagged, and stored in object storage with the URL recorded in the delivery record. A dispute log links evidence URLs to each reported case for structured resolution.

How does the platform handle high-volume notification delivery?

Notifications are event-driven: order_events publish to a notification router that dispatches via FCM, APNs, SMS, or email based on customer channel preference. Templates are managed in a database table (not hardcoded), enabling per-locale customisation without a deployment. Failed deliveries retry with exponential backoff and a notification_log tracks delivery status for every message sent.

How do merchant integrations work for e-commerce delivery platforms?

Merchant integrations use outbound webhooks with HMAC-SHA256 request signing and a configurable retry policy with exponential backoff. E-commerce connectors pull orders from Shopify and WooCommerce via REST and push status updates back on each state transition. An integration_log records every delivery event and dispatch status. Returns management creates a return_order from any failed delivery and synchronises the return status back to the merchant system.