Example
Work / Field service
Field work, signal or not.
An offline-first job app for maintenance crews, built so a work order never waits on a bar of reception.
An illustrative example. No client is named here until we have their written consent.
Case facts
- Client
- A utilities maintenance contractor
- Sector
- Utilities maintenance
- Team
- A senior engineer, a designer, and the client's field lead
- Platforms
- Android · iOS
The work
What the crews needed, and what we built
Maintenance crews spend the day in basements, plant rooms and roadside cabinets — the places mobile coverage forgets. The office still needs to know what happened down there, and it needs to know before it plans the next morning.
The challenge
The tooling in use assumed a connection. A form submitted underground failed quietly, so crews photographed jobs on their own phones and typed them up at the end of the shift. Records arrived late, in a shape nobody could audit, and a repeat visit was often the first sign that something had been lost.
We rode along with the crews before writing anything. The real constraint was not bandwidth — it was that nobody trusted the app to have kept what they put into it.
The approach
We made the device the source of truth for the length of a shift. Work orders sync down before a crew leaves the yard, every capture writes to a local store first, and reconciliation runs in the background the moment a connection returns. Conflicts follow a rule the office agreed in a workshop, rather than one the app decided on its own.
- A local-first store with a sync log the crew can read for themselves.
- Photos and signatures captured at full quality, uploaded when bandwidth allows.
- One screen per job, legible in gloves, daylight and a dark plant room.
The outcome
Jobs are now finished on site instead of in the evening, and the office sees each one as soon as a van is back in range. The part the client asked us to keep was the sync log: seeing exactly what had been saved, and what had not, was what earned the app its trust.
Written as an illustrative case. The situation, the decisions and the shape of the work are representative of how we run a project like this; nothing here identifies a real client.
The application
One job, one screen, no connection required.
Job view, offline.
The problem
Paper was catching what the software dropped.
Every crew had its own workaround: a notebook, a camera roll, a message thread with the dispatcher. None of it reached the system on the day it happened, and none of it could be reconciled afterwards without asking someone to remember.
The cost was not the typing. It was that the office planned each morning from a picture it knew was incomplete.
- Submissions failed quietly, with nothing kept locally.
- The same job was written down twice, in two formats.
- Paperwork ate the end of every shift.
The build
Offline is the default, not the fallback.
The app writes to the device first and treats the network as an event that may or may not arrive. Every record carries its own state — captured, queued, reconciled — and the crew can see which state a job is in without asking anyone.
Synchronisation is boring on purpose: a small, ordered log, replayed in the same sequence every time, with conflicts resolved by rules the office wrote down.
- Local store first; the network is an event, not a prerequisite.
- An ordered upload queue that survives a restart.
- Conflict rules agreed with the office, written into tests.
In their words
Our crews work in places with no signal at all. The app simply keeps going, and the office sees the job the moment they are back in range.
An illustrative quote from an example engagement, not a real client statement.
Screens
The three moments of a job.
The day's orders, synced before the crew leaves the yard. Capture, with the photo queue visible. Sign-off, taken on the device.
This case study is an illustrative example. The client, the quote and every image are placeholders; no real engagement is described or named.See the rest of the work