Every driver app vendor says they work offline. Most mean "the app does not crash when signal drops". Genuine offline-first design is an architectural decision, and the difference is visible within a week of go-live.
Where connectivity actually fails
Not in remote countryside, mostly. In the places deliveries happen:
- Loading docks and basements
- Multi-storey car parks
- Industrial estates with poor coverage
- Inside large buildings — hospitals, warehouses, retail back-of-house
- Rural lanes and valleys
- Congested cells at peak times, where a connection exists but is unusable
- Border areas, where roaming behaviour is unpredictable
The last two matter more than people expect. An app that handles no signal correctly may still hang on bad signal, which is a far more common condition.
What offline-first requires
Local data store as the primary source. The app reads and writes to a local database. Sync is a background process, not a prerequisite for the driver doing their job.
Full route data cached before departure. The entire manifest, customer details, access notes, product catalogue and prices, downloaded at the depot on wi-fi.
Local write with queued sync. Every action — completion, photo, signature, exception — is written locally and queued. The driver never waits for a network round trip.
Idempotent sync. Retried uploads must not create duplicates. This is where weak implementations fail: a driver completes a stop, the upload retries, and the office sees two deliveries.
Conflict resolution rules. If the office cancels a stop while the driver is offline completing it, what happens? There must be a defined rule, and the driver must see the outcome.
Graceful degradation. Features that genuinely need connectivity — live traffic, a call to a customer — should fail clearly, not hang.
Storage management. Photos are large. The app needs a policy for local retention, upload prioritisation and cleanup, or devices fill up mid-week.
Timeouts that are short. An app that waits 60 seconds for a response on a bad connection is worse than one that gives up in three and queues.
Sync design that works
Prioritise. Not all data is equal. Status updates and completions should sync before photographs; the office needs to know a delivery happened before it needs the image.
Chunk and resume. Large photo uploads must resume rather than restart when a connection drops mid-transfer.
Compress images on device. A full-resolution photograph is unnecessary for proof of delivery and expensive to transmit. Compress to a defined standard before queuing.
Opportunistic sync. Upload whenever connectivity appears, not on a fixed timer.
Wi-fi preference for bulk. Queue large items for depot wi-fi where the operation allows it.
Visible queue status. The driver should be able to see that six items are pending upload. Invisible queues produce anxiety and end-of-day re-entry.
Conflict scenarios to specify
Agree the behaviour for each of these before go-live:
| Scenario | Decision needed |
|---|---|
| Stop cancelled centrally while driver is offline and completes it | Which wins, and who is notified |
| Price changed centrally after device download | Use downloaded price or reject the transaction |
| Additional stop added while driver is offline | When and how it reaches the device |
| Driver edits a completed stop before sync | Allowed, or locked after completion |
| Same stop completed on two devices | Detection and resolution |
| Device lost with unsynced data | Recovery path, and what is lost |
That last one deserves a written procedure. Unsynced data on a lost device is gone; the operational question is how you reconstruct the day.
Evaluating a vendor's claim
Ask these, and require demonstrations rather than answers:
- Is the local store a full database, or a cache of recent screens?
- What is the maximum time the app can operate with no connectivity?
- How is duplicate submission prevented?
- What happens to a partially uploaded photograph?
- How does the driver know what is pending?
- What is the conflict resolution rule for a cancelled stop?
- How much local storage is required for a full day, including photos?
- What happens on app update mid-shift with unsynced data?
Question 8 catches out several products: a forced update that discards the local queue is a data loss event.
Frequently asked questions
How much local storage should we allow?
Enough for a full day's manifest plus photographs at your compression standard, with a comfortable margin — several gigabytes free is a reasonable planning figure. Devices that fill up produce failures that look like app bugs and are actually storage exhaustion.
Should drivers be able to work offline all day?
Yes, and some genuinely will. Design for it as the normal case rather than as an emergency, and the app will handle intermittent connectivity gracefully as a side effect.
What about live ETAs when the driver is offline?
Customer-facing ETAs degrade during an offline period; the system should extrapolate from the plan rather than showing nothing, and update when the driver reconnects. Tell customer service how this behaves so they can explain it.
Is a web app acceptable for drivers?
Progressive web apps can work offline with careful engineering, but native applications generally handle background sync, storage, camera access and power management better. Judge on demonstrated behaviour rather than on architecture preference.
How do we handle a device that never syncs?
Alert on it. A device with unsynced data older than a defined threshold should raise an operational alert, not sit silently. Most operations discover this requirement after their first lost day of data.
