Most apps are built cloud-first: the server holds the truth, the client is a thin, disposable view onto it, and "offline support" — if it exists at all — is a cache layer bolted on afterward to paper over the times the network isn't there. That ordering is exactly backwards for a growing set of applications, and it shows up as bugs the moment connectivity gets flaky instead of fully absent.
The cache-as-afterthought problem
Bolting offline support onto a cloud-first app usually means: cache the last known server response, let the user view it, and queue up writes to replay once the connection comes back. This works until two clients edit the same data while both are offline — at which point "replay the queued writes" becomes "whoever reconnects second silently overwrites whoever reconnected first," and the app has quietly become a data-loss machine with a spinner on top.
What local-first actually assumes
Local-first flips the starting assumption: the local copy of the data is the primary one the user interacts with, full stop, and sync to a server (or to other devices) is a background process that reconciles state — not the precondition for the app being usable at all. That single flip forces different decisions much earlier in the design:
- Conflict resolution has to be a real, designed mechanism — CRDTs, operational transforms, or an explicit merge strategy — not an incidental side effect of "last write wins," because concurrent offline edits are the normal case, not a rare edge case to shrug off.
- The client needs a real local data store, not just a response cache, because the app has to be fully functional — reads and writes — with zero network.
- Sync becomes a background reconciliation problem, closer to distributed systems replication than to a typical REST request/response cycle.
Why this is spreading beyond note-taking apps
The category most associated with local-first is still small — collaborative editors, note-taking tools. But the underlying problem (an app that needs to stay fully usable and correct across unreliable connectivity) applies far more broadly than that: field service tools, point-of-sale systems, anything used somewhere with spotty connectivity by design. The tooling (CRDT libraries, sync engines) has matured enough that "local-first" is shifting from a research topic to an architectural option you can actually reach for, rather than a from-scratch research project every team has to solve alone.
The actual takeaway
If your app's offline behavior is "shows a loading spinner and a retry button," that's not local-first, it's cloud-first with a worse network. The distinction matters because the two produce genuinely different failure modes under the same bad connection — one degrades gracefully, and one loses data quietly and tells you it succeeded.
