A driver and dispatch app for a fast-scaling courier

Axel Express was scaling fast — more parcels, more drivers, more routes — and the tooling had not kept up. Drivers were juggling printed manifests, phone calls to dispatch, and a generic delivery app that did not know about their specific workflows. Dispatch was relaying status updates by hand. They needed a driver-first mobile experience and the dispatch back-office to match.

The Challenge

Driver apps fail when they ignore the conditions they actually run in. A driver is often using the app one-handed, in poor light, on a connection that drops without warning. Anything the dispatch team needs captured — proof of delivery, exceptions, customer signatures — has to be fast to record and resilient when the network goes down. Three taps where one will do is enough to make the app get bypassed.

On the dispatch side, the operations team needed a real-time view of the fleet without calling drivers to ask. And because Axel Express runs deliveries every day, the rollout had to happen without disrupting live operations.

Our Approach

The driver app was built offline-first from day one. Every action — scan, capture, signature, status change — queues locally and reconciles with the server when the connection comes back. The UI was designed against the real interaction model: thumb-reachable controls, large tap targets, dark-mode by default, and visible queue state so the driver always knows what has and has not synced.

The dispatch back-office runs in the browser and shares a live realtime channel with every connected driver. Status updates appear within seconds; exceptions surface as actionable cards rather than buried lines on a manifest. The two surfaces (driver and dispatch) were built against the same domain model, so the language used in the office matches what is on the driver's screen.

Rollout

• Weeks 1–3 — Field shadowing and workflow mapping: ride-alongs on three routes, exception cases catalogued, domain model agreed with dispatch
• Weeks 4–9 — Driver app build: offline sync layer, scanning, signatures, status changes, exception capture
• Weeks 8–13 — Dispatch back-office and realtime channel (started while the driver app was still in build, finished after it stabilised)
• Weeks 14–16 — Pilot with one route for two weeks, expansion to the full fleet
• Weeks 17–18 — Retire the legacy app, harden the realtime channel, on-call setup

What We Built

Driver app

React Native (iOS + Android), offline-first sync

Dispatch web

React, TypeScript, realtime channel

Backend

Node.js (Fastify), PostgreSQL, Prisma

Realtime

WebSocket-based status propagation

Maps & routing

Mapbox

Infrastructure

AWS (ECS, RDS, S3), GitHub Actions, EAS for app delivery

Results

Drivers run their day from the app. Manifests, scans, signatures and exception capture all happen in one place; the queue indicator shows them exactly what has and has not synced, so a dropped connection in the middle of a delivery no longer creates uncertainty. Dispatch sees the full fleet in real time rather than calling drivers to ask.

The two-week pilot on a single route surfaced the kind of edge cases that only appear when an app meets real conditions — gloves, glare, the moment of weak signal at the back of a yard. Each was fixed before the full-fleet rollout. By week eighteen the legacy app was retired and on-call coverage was in place.

The app's value came from how it performed in the conditions drivers actually work in — patchy signal, one-handed use, the moment a parcel is half out of the van and a customer is waiting. Designing against those constraints from week one is what made the difference at rollout; the dispatch side was a comparatively straightforward web app once the domain model was settled.