Field notes2 Apr 2026 · 8 min read

Offline-first is non-negotiable on a plant room roof

A field report: what it actually takes for a maintenance mobile app to keep working when the 4G bar disappears — and the trade-offs we made to get there.

The field problem

A commercial boiler room three floors below ground. A substation in a cage at the back of a trading estate. The ceiling void of a Victorian retail unit. These are the environments where maintenance work happens, and they have one thing in common: no signal.

An engineer who has to wait for the app to sync before they can log work is an engineer who writes on paper instead. Paper never syncs.

What offline-first actually means

Every write — job status, photo, signature, part used, time log — lands in a local IndexedDB queue first. The UI treats the local write as truth. When the network comes back, the queue drains to the server, and any conflicts get resolved with last-write-wins-per-field.

It's not glamorous. It's mostly about giving up on the idea of a 'saving…' spinner and accepting that the local copy is the real copy until you have other evidence.

The trade-offs

You lose optimistic uniqueness checks — the server can't tell you another engineer already picked up that job until you're back online. You work around it with explicit reservations. You also carry more client-side logic than you'd like. Worth it, because the alternative is paper.

Written by FMan team← All posts