Offline-first is a data-layer decision, not a feature you add later
Retrofitting offline support into an app that assumed connectivity is close to a rewrite. The reason is that offline is not a feature - it is an assumption about who owns the truth.
Almost every mobile brief contains the phrase should work offline, usually near the bottom, usually without an estimate attached. It is treated as a feature, sitting alongside push notifications and dark mode.
It is not a feature. It is a decision about where the authoritative copy of the data lives, and it has to be made before the first screen is built.
The two architectures
In a connected app, the server owns the truth. The device holds a cache, the UI reflects a request in flight, and a failure means showing an error and retrying. This is simple and correct for a great many apps.
In an offline-first app, the device owns the truth for as long as it holds it. Writes succeed locally and immediately. Sync is a background reconciliation between two sources that have both changed, and conflict is a normal condition rather than an error.
Those are not two points on a spectrum. They are different programs.
Why retrofitting is so expensive
A connected app expresses uncertainty everywhere: loading states, disabled buttons, spinners tied to requests. Converting it means removing all of that and replacing it with local writes plus a sync indicator - which touches every screen that writes anything.
Worse, the data model usually assumes server-generated IDs. Offline creation means the device must mint identifiers the server later accepts, and every foreign key written against a temporary ID has to be rewritten when the real one arrives. That reaches into places nobody expected.
Retrofitting offline is not adding a cache. It is changing who is allowed to be right.
The questions that decide it
- Can a user create or edit data with no connection, or only read stale data?
- If two devices change the same record offline, who wins - and can the user see that a decision was made?
- How long may local data diverge before it is unsafe to act on?
- Is there anything the app must refuse to do offline, such as a payment?
Answer those in discovery and the architecture follows. Leave them and you will answer them anyway, in the third month, at considerably greater cost.
The honest middle ground
Most apps do not need full offline-first. They need read-anywhere with a clear staleness indicator, and a small set of writes that queue. That is far cheaper and covers the real complaint, which is usually opening the app on the underground and seeing nothing at all.
Scoping that precisely - these three actions queue, everything else needs a connection - turns an unbounded requirement into a week of work.
