Why we default to offline-first, even when the client doesn't ask

Most apps are built and tested on office wifi, then shipped to people standing in a basement, a lift, a warehouse, or a village with one bar of 4G that keeps handing over to 2G.

The usual failure isn’t a spinner. It’s silent data loss: the user taps save, the request times out, the UI clears the form, and nobody finds out until reconciliation next month.

What we do instead

Writes go to a local store first and return immediately. A background worker drains the queue when the radio is available. Every record carries a client-generated ID and a logical timestamp, so a retry can’t create duplicates and a late-arriving write can’t clobber a newer one.

The cost is real: you now have two sources of truth and a merge policy to design. But you pay that cost once, at the start, in exchange for an app that never loses a user’s work.

When it isn’t worth it

Read-heavy apps with no offline writes. Internal tools on a fixed LAN. Anything where a stale read is more dangerous than a failed one — trading, live inventory allocation, seat booking.

Everything else, we default to it.