The signal drops. The work doesn't.
A field-operations app for the fuel logistics of a national telecom operator. Agents log trips, sites, consumption and distance from places with no coverage — and the data is waiting on the server the moment they are back in range.
Figures pending. The three numbers that would carry this case study, and none of them is in the record we were given. Ask the client before launch. Nothing is published here until one of them is confirmed.
What does a field app do when there is no network?
Most apps answer that question badly, because most apps answer it late. Connectivity is assumed, then patched: a spinner, a retry, a toast saying the save failed. That is survivable on a train. It is not survivable at a fuel depot outside the city, where an agent has six sites to visit, no bars, and a paper fallback waiting to reappear the moment the app wastes their time.
Once the paper comes back, the system has lost. The readings get written down, transcribed in the evening, transcribed again into a spreadsheet, and every number the operation depends on is a day old and a copy of a copy.
So the app was built the other way round. The local database is the source of truth at the moment of capture; the server is where that truth goes when it can. The agent never waits for a network to finish their job, and never has to remember what they have and have not sent.
Seven decisions, one of them structural.
The first three are the same decision seen from three angles. The rest is the operation itself.
- Offline capture. Every form writes locally first. Coverage is treated as an optional extra, not a precondition.
- Sync on reconnect. Queued work uploads the moment the network returns, without the agent doing anything.
- Manual sync and status. An explicit online/offline indicator and a sync button, because an agent about to leave a depot wants to know, not guess.
- Trip and task scheduling. A daily calendar of what to visit and in what order.
- Fuel site management. Each site carries its own data, so a reading is attached to a place rather than a note.
- Consumption and distance logging. The two numbers the operation runs on, captured at the point they are known.
- Error-resistant entry. Forms built for gloves, sun and hurry — large targets, few free-text fields, validation before submit.
The one worth dwelling on is the status indicator. It is the smallest thing in the list and the one that decides whether the app is trusted: an agent who can see that eleven entries are queued and none are lost will keep using it, and an agent who cannot will start keeping a second copy on paper — at which point the app is overhead rather than infrastructure.
The same problem, in four other industries.
Fuel logistics is not a special case. Anywhere the work happens away from a desk, the network is a variable and not a given — and the pattern this app is built on is the same one that makes those apps usable.
- Inspection and maintenance. Plant, utilities, infrastructure — readings taken in basements and substations.
- Logistics and delivery. Proof of delivery captured at a door with no coverage, reconciled later.
- Agriculture and site survey. Data collected across land that has never had a mast on it.
- Health and social outreach. Visits recorded in the field, where the alternative is a form in a bag.
- Flutter
- Dart
- Bloc
- REST API
- Firebase
- Local persistence
- Sync queue
- Role
- Mobile app development
- Period
- 2024 — 2026
- Platform
- Flutter, one codebase, iOS and Android
- Availability
- Internal app — issued to field agents only, so there is no public store link.