Offline-first is a product decision, not an engineering one

Every team says they support offline. What they usually mean is that the app does not crash without a network — it shows a spinner, then an error, then a retry button. That is not offline support. That is a graceful failure.

Design the empty state first

When we start a new app we sketch the disconnected screen before the connected one. If a feature has no meaningful disconnected state, that is a signal about the feature, not about the network layer. Sometimes the answer is to cache more aggressively. Often the answer is that the feature is less essential than we assumed.

If the most important thing your app does needs a server, you have built a website with an app icon.

Three rules we hold to

1. 01The primary answer — the one sentence the user opened the app for — resolves locally.
2. 02Writes are queued and reconciled, never blocked on a round trip.
3. 03Anything requiring the network is visibly optional, so its absence reads as expected rather than broken.

The cost is real

Offline-first is more work. You take on cache invalidation, conflict resolution and a larger install size. It pays off when your users are on unreliable connections, when the app is checked in short bursts, or when being wrong is worse than being slow. It does not pay off for a dashboard that is meaningless without live data.

The honest framing is that offline-first buys reliability with complexity. Know which one your users are short of.