A short guide to offline-first design

It comes up on almost every project, usually later than it should. Everything we would tell a client about offline-first design in the time it takes to drink a coffee.

You do not control the device, the network, or the operating system version, and the design has to accept that. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

Why it matters

Connections drop, and the app should keep working. The cost of getting this wrong is rarely visible on the day it happens. If it only works because one person remembers to do something, it does not work yet.

Where to start

Conflict resolution is the part teams forget to design. Where this goes wrong is almost never a lack of knowledge. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

The mistakes we see most

Show sync state so people trust what they see. That sounds obvious written down. It is still the thing most often skipped. Assume whoever inherits this will have half your context and none of your patience.

How to tell if yours is fine

The version of the app your customers are running is rarely the one you just shipped. Three things worth confirming about offline-first design before you move on:

• Someone can say what the current setup is without going to look
• Conflict resolution is the part teams forget to design — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Pick the one that would hurt most if it failed, and start there.