Offline first habit tracking: what it means in practice

Offline first gets used as a synonym for “works without signal”, which undersells it. The real meaning is architectural: your device holds the authoritative copy, every write succeeds locally first, and the server (if there is one) is a replica that can disappear without taking your data with it.

The difference shows up in three situations. On a bad connection, an offline first app logs instantly and reconciles later, while a server first app shows a spinner and sometimes loses the tap. When the company shuts down, an offline first app keeps working with your history intact, while a server first app becomes a login screen. And when you want your data out, an offline first app already has it on the device in a file you can copy.

There is a cost, and it is conflict resolution. Two devices editing the same day while offline produce two versions and something has to decide. Server first apps avoid the problem by refusing the write. Offline first apps have to resolve it, and the honest ones tell you when they did.

This page explains the three architectures you will encounter, how to tell which one an app uses from the outside, what to test in the first week, and the specific questions to ask about conflict handling before you trust two devices with the same habit.

Outline

Status: outline. The introduction above is finished copy. Everything below is the section plan for the full draft, targeted at about 1 400 words.

1. Three architectures. Server first, cached, and offline first, with the trade-off of each.
2. Telling them apart. Three tests you can run in aeroplane mode in five minutes.
3. What happens when the company stops. The scenario worth planning for.
4. Conflict resolution. Last write wins, merge, and prompting, with worked examples.
5. Where the file lives. On-device storage, backups, and whether you can copy it.
6. The first week test. Four things to try before you commit a year of logs.