Three myths about offline-first design
The advice here is unglamorous, which is probably why it gets skipped. A few things about offline-first design that get repeated more often than they get checked.
You do not control the device, the network, or the operating system version, and the design has to accept that. Assume whoever inherits this will have half your context and none of your patience.
“It only matters for big sites”
Connections drop, and the app should keep working. Getting it slightly wrong is survivable. Ignoring it entirely is not. It rarely shows up as a line item, which is exactly why it slips.
“We can deal with it after launch”
Sometimes true, usually expensive. Where this goes wrong is almost never a lack of knowledge.
“Our platform handles it”
Show sync state so people trust what they see. In practice this is a scheduling problem more than a technical one. The version that survives contact with a real deadline is the simple one.
What this looks like day to day
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
If you are not sure where your systems currently stand on this, it takes us about an hour to find out.