Insights · Mobile
Offline-first is a feature your users will never notice
…until the clinic Wi-Fi drops. What we learned building for patchy networks.
When we started the clinic booking project, the requirements said nothing about offline support. Then we visited a clinic. The Wi-Fi in the waiting room was a router behind a fridge, and mobile reception in the basement treatment rooms was a single bar on a good day.
Design for "eventually", not "now"
An offline-first app treats the local database on the phone as the source of truth for the user interface. The network is just a way to sync it. Every action — book, cancel, reschedule — is written locally first and queued for upload.
Three rules we now follow on every app
- Every write gets a client-generated ID. If the upload is retried five times, the server still creates one appointment, not five.
- Show sync state honestly. A small "waiting to sync" label beats a spinner that never ends — and beats pretending something saved when it didn't.
- Decide conflicts on the server, explain them on the client. If two people grab the same 10:30 slot, one of them must get a clear, friendly message and a suggested alternative.
Test it like the real world
Both major mobile platforms let you throttle the network in development. We add a "bad network" profile to every test plan: high latency, 5% packet loss and random disconnects. It finds bugs that a fast office connection never will.
The pay-off
Nobody has ever thanked us for offline support. That's the point. Users simply find that the app always works — and they keep using it.