Building an offline-first driver app

Driver app development has one non-negotiable requirement that most first versions get wrong: the app must work when the phone has no signal. A rider in a basement car park, a driver on a highway between towers, a delivery partner in a lift, all need to mark a stop complete, capture a photo and move on. An app that shows a spinner in those moments gets abandoned for a phone call to the hub, and the operation loses its live data. Offline-first is not a feature of a delivery partner app; it is the architecture.

This article sets out how we build a rider app for India and similar markets: what lives on the device, how sync works, how conflicts are resolved, the battery and data budget, and what a build costs.

What offline-first means in practice

Offline-first means the local database on the phone is the source of truth for the rider's day, every action the rider takes is written there first and acknowledged instantly, and a background process synchronises with the server whenever it can. The rider never waits for the network, the server never assumes it has the latest state, and the two are reconciled by rules decided in advance rather than by whichever write arrived last. The alternative, an app that calls the server on every tap, is what most operators have.

Online-only vs offline-first

Data design: the event log is the app

The centre of an offline delivery app is an append-only log of actions on the device: stop arrived, stop completed, photo captured, COD collected, exception raised, location sampled. Each action has a client-generated ID, a timestamp, the rider and the order it applies to, and a sync status. The screens are projections of that log plus the manifest the server sent. Sync is the process of pushing unsynced actions to the server in order and pulling the server's changes since the last sync token. Because every action is idempotent (the server has seen this client ID or it has not), retries are safe, duplicate uploads are harmless, and a crash mid-sync loses nothing. The general design is covered in offline-first mobile apps: design, sync and conflicts; the driver app is its most demanding case.

What lives on the device

• The day's manifest: stops, sequence, customer contact, instructions, COD amounts
• The action log with sync status
• Photos and signatures, compressed, with a retention rule after successful upload
• A location buffer with adaptive sampling (more often when moving, less when stationary)
• Reference data: hub addresses, exception reasons, scripts for customer calls
• Nothing the rider does not need for today; the app is not a database browser

Conflict resolution by rule

Conflicts are inevitable when two parties change the same order while one is offline. The rules are decided with operations, not left to the code. Completed work wins: if the rider delivered a stop the hub later reassigned, the delivery stands and the reassignment is cancelled with a notification. Server data wins for reference fields: if the customer's address was corrected at the hub, the rider gets the new one on next sync. Additive changes merge: a new stop added by dispatch appears in the rider's list; the rider's exception on another stop is preserved. Ambiguous cases are surfaced, not guessed: a COD amount that differs between rider and server is flagged for the hub to reconcile. Writing these rules down before development is the most valuable day in the project.

Sync, battery and data budget

A rider app India-wide has to respect cheap phones, small data plans and long shifts. Sync is batched and compressed, runs when connectivity is detected rather than on a timer, and uploads photos on Wi-Fi or a background schedule unless the operator needs them immediately. Location sampling adapts to motion so a stationary phone stops burning battery on GPS. The app is built to survive the operating system killing it: state is on disk, not in memory, and the location and sync services restart. The Android background work guidance sets the constraints, and we test against them on the phones riders actually carry, not on flagship devices.

React Native or native?

We build most driver apps in React Native with native modules for location and background sync, because one codebase covers Android and the smaller iOS fleet and the offline data layer is where the engineering effort belongs. A fully native build is justified when the app needs hardware integration beyond the usual (thermal printers, specialised scanners) or when a platform-specific background behaviour cannot be reached otherwise. See our React Native mobile service for the trade-offs.

The rider's day, screen by screen

Good driver app UX is fewer taps under worse conditions: one-thumb operation, large targets, high contrast in sunlight, and the next action always obvious. Start shift and vehicle check; accept the manifest; navigate to the stop with the customer's instructions visible; arrive; deliver with photo, OTP or signature; collect COD with a visible running total; raise an exception from a short list with a photo; end shift with a summary that matches what the hub sees. A sync indicator shows unsynced actions so a rider knows the app has their work, which removes the anxiety that drives duplicate calls.

Where AI fits

The app is the event source for everything intelligent in the operation. Exception events trigger a delivery exception agent that messages the customer while the rider moves on; location streams feed honest ETAs; the action log feeds dispatch for the next assignment. On the device, small models can read a handwritten address, check a proof-of-delivery photo for legibility, or transcribe a voice note into an exception, all working offline. See AI in logistics for the operation-level picture.

A worked example

A last-mile operator's riders used an app that called the server on every action; in dense urban areas with patchy signal, riders phoned the hub to confirm deliveries and the hub updated the system by hand, so the dispatch view was hours behind. We rebuilt the app offline-first: manifest on the device, an action log with idempotent sync, photos uploaded in the background, adaptive location sampling and conflict rules agreed with the operations team (completed work wins; server wins for reference data; COD differences flagged). The app was tested on the operator's own low-end devices and in known dead zones. The hub's phone traffic fell away as riders stopped needing confirmation, dispatch saw the day in near real time, and the exception agent had events to act on. The dispatch platform and field apps case study describes the full build.

Team and timeline

An offline-first driver app is typically a mobile lead, a backend engineer for the sync API and conflict handling, a designer for the field UX, and a QA engineer with a box of cheap phones, over ten to sixteen weeks. The first weeks design the data model and conflict rules and build the sync layer with tests; the middle weeks build screens against it; the last weeks run a pilot with a handful of riders in real conditions, tune battery and sync, and roll out by hub. React Native mobile builds start from $17,500 / ₹11.2L, with the API and integrations work for the sync backend from $7,000 / ₹4.4L; a full dispatch platform alongside is a product and platform development engagement. Current figures are on the pricing page, and the logistics sector page lists related work.

Before you start: a checklist

• Write the conflict rules with operations before any code: completed work, reassignments, COD, addresses
• List every rider action and make each one idempotent with a client ID
• Decide what must be on the device for the day and what stays on the server
• Set the photo policy: compression, upload conditions, retention after upload
• Choose location sampling rules and the battery budget per shift
• Collect the actual phones riders carry and test on them in dead zones
• Plan rollout by hub with a rollback path to the old app

Glossary

• Offline-first: the local store is the source of truth on the device and sync happens in the background
• Action log: an append-only list of the rider's actions with client-generated IDs and sync status
• Idempotent: an action that can be sent more than once without duplicating its effect
• Sync token: a marker of the last server change the device has seen, used to pull deltas
• Conflict rule: a pre-agreed decision about which change wins when both sides edited the same record
• Adaptive sampling: changing location frequency based on motion to save battery

Related reading

See field service apps: what technicians actually need for the sister problem, on-device AI in mobile apps for what small models can do offline, and dispatch and routing engines for the system that consumes the app's events.

Design the event log first, decide conflicts with operations, test on the phones riders carry, and the app keeps working when the network does not.