Offline-first shop-floor apps: keeping work going when the network drops

Factory Wi-Fi drops. A metal rack, a forklift or a crowded access point is enough. If the app stops when the network does, operators write on paper and the data is lost or typed in later with mistakes. An offline-first app treats the network as optional.

Write locally first

Every action is saved on the device before anything is sent. In a browser or tablet app that means IndexedDB, or SQLite on a native app. The screen reads from the local store, so it responds the same whether the network is up or not. A background process then sends queued records to the server and marks each as synced when the server confirms.

A service worker lets a web app load with no connection at all, so the app shell itself must be cached, with the data.

Give every record an identity at creation

Create the ID on the device, as a UUID, not on the server. Then a record made offline can be referred to, edited and linked straight away. Send that ID with the upload as an idempotency token, so a retry after a half-finished request does not create a second record. Retries are normal on a weak connection, so the server must treat them as normal.

Decide how conflicts are settled

Two tablets will sometimes change the same record. Choose the rule per field, in advance.

• Append-only events, such as “unit 1042 passed station 3 at 14:05”, rarely conflict. Prefer them.
• Counters should be sums of events, not a number overwritten by whoever syncs last.
• Status fields that people edit may need last-write-wins, or a prompt that shows both versions.

Device clocks drift, so use server time for ordering, and store the device time as a separate field.

What must never be lost

Make a short list and treat it differently. Test results tied to a serial number, quality rejects, calibration records and anything that goes into a customer certificate are examples. For these, the app should keep the local copy until the server has confirmed it, show a visible count of unsynced records, and warn before a user logs out or clears data. Ask for persistent storage from the browser, since a device low on space may otherwise clear a local cache.

Test the failure

Switch off the router during a shift trial. Pull the plug mid-upload. Restart the tablet with 200 queued records. Most bugs show up in these three tests.

What this does not cover

Offline-first does not help when the work depends on live data, such as checking stock in the ERP before issuing material. Show the last synced value with its age, and let a supervisor decide how stale is acceptable.

---

If your line stops whenever the network does, we build micro-apps for electronics and manufacturing that keep working locally, so book a discovery call.