Offline-first design: the questions we get asked most

This is one of those topics that looks small until it costs you something. The questions about offline-first design that come up most often on our calls.

Mobile releases are slower to correct than web ones, so the cost of shipping a mistake is higher. Write the reasoning down alongside the decision, because the reasoning is what changes first.

Do we need to care about this?

Connections drop, and the app should keep working. Getting it slightly wrong is survivable. Ignoring it entirely is not. Budget a little time for it every quarter and it never becomes a project of its own.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. It is worth being explicit about, because assumptions differ quietly.

How do we know it is working?

Show sync state so people trust what they see. None of that requires a large budget, only a decision and someone to own it. Check it against what you would want a competitor's site to get wrong.

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
• Show sync state so people trust what they see — and you know whether that is true here
• There is a way to tell whether the last change to this helped

None of this needs a rewrite. Most of it is a morning's work once someone decides to do it.