Cargoline Freight

Mobile application

The challenge

Cargoline planned routes overnight and dispatched them at 5 a.m. By 9 a.m. roughly a third of those plans were invalid — pickups cancelled, docks backed up, weather rerouting. Drivers handled it by phone, dispatchers re-planned in their heads, and the resulting empty-mile rate ran 31% against an industry benchmark near 22%. The existing driver app assumed connectivity that simply doesn't exist across large stretches of the network's rural lanes.

Research

• Ride-alongs on 40 routes across urban, suburban, and rural lanes
• Cellular connectivity mapping along the 200 highest-volume lanes
• Analysis of 90 days of dispatch phone logs to categorize exception types
• Backtesting of candidate routing models against two years of historical loads

The solution

The routing engine re-optimizes continuously rather than once nightly — every telemetry update, dock status change, and cancellation feeds a constraint solver that can revise assignments mid-route. Crucially, it re-plans conservatively: drivers who receive constant route changes stop trusting the system, so revisions are gated on a materiality threshold tuned during rollout. The driver app is offline-first by default with a deterministic sync engine, treating connectivity as the exception rather than the assumption.

UX decisions

Features

• Continuous route re-optimization against live telemetry
• Offline-first driver app with deterministic conflict resolution
• Exception-first dispatch control with automated escalation
• Shipper self-service portal for quoting, booking, and tracking
• Cross-dock throughput planning across 22 terminals
• Lane profitability analytics with accessorial attribution
• Electronic proof of delivery with offline capture

Technology

Architecture

Vehicle telemetry and dock events stream into Kafka. A Go service maintains live fleet state; a Python optimization service runs the constraint solver against a rolling horizon, publishing revisions only above the materiality threshold. The React Native driver app maintains a local SQLite store as source of truth for the driver's own actions, syncing via an append-only log with last-writer-wins on server-authoritative fields and driver-authoritative resolution on capture data — a driver's proof of delivery always wins. Runs on EKS with regional sharding by terminal group.

Results

Empty miles fell from 31% to 24%, worth roughly $3.4M annually in fuel alone at deployment-year prices. On-time delivery rose from 88.1% to 96.4%. Driver-to-dispatch phone escalations dropped 61%, which dispatchers described as the single most noticeable change in their day. Driver app adoption hit 97% within six weeks without incentive programs.

Lessons learned

1. 01Conservative re-optimization beat optimal re-optimization decisively. The mathematically better solver produced worse real-world outcomes because drivers stopped trusting it.
2. 02Offline-first is an architecture, not a feature. Our first design treated it as a degraded mode and it failed rural testing badly enough to require a rewrite of the sync layer.
3. 03The fleet map we were most proud of got cut. Impressive-looking dashboards that don't drive action are a tax on the people using them.