Open a note-taking app in a tunnel and watch what happens. Some show you your notes instantly and sync later. Others show a spinner, then an error, then nothing — despite the fact that your notes are a few kilobytes of text that could trivially have been stored on the device you are holding.
The short version
- Cloud-first apps treat the server as the truth and your device as a viewport. No network, no application.
- Local-first treats your device as authoritative and sync as a background process.
- The hard part is merging concurrent edits, which is why most products avoid it.
- The real argument is longevity: your data outlives the company.
Two different assumptions about where truth lives
In a cloud-first design, the server holds the authoritative copy. Your client fetches a view of it and sends changes back. This is straightforward to build and reason about, and it fails completely the moment the network does — because the client was never holding anything real.
In a local-first design, the authoritative copy is on your device. Writes go to local storage immediately and the interface updates without a round trip. Synchronisation happens in the background, and other devices converge when they can reach each other.
The difference is not a caching strategy. It is a decision about who owns the truth — and it determines whether the application still exists when the network does not.
What local-first buys you
- Immediate response. No spinner between your keystroke and the result, because nothing crosses a network to render your own edit.
- Genuine offline use. On a plane, in a basement, on a bad connection, the application behaves normally.
- Ownership. Your data is on your disk in a form you can copy, back up and inspect.
- Survivability. If the company shuts down, a local-first application degrades to a local one. A cloud-first application becomes an icon that opens an error.
That last point is the strongest argument and the least discussed. Services are discontinued routinely. The question of what remains afterwards is an architectural decision made years earlier.
Why it is genuinely hard
The difficulty is not storing data locally — that part is easy. The difficulty is what happens when two devices edit the same thing while unable to see each other, and both edits are legitimate.
Cloud-first systems dodge this by serialising every change through one server. Remove that and you need a merge strategy that produces a sensible result without asking the user to arbitrate.
Approaches to merging
- Last-writer-wins. Simple, and silently discards work. Acceptable for a toggle, unacceptable for a document.
- Operational transformation. Transforms concurrent operations so they compose correctly. Powerful, and notoriously difficult to implement correctly.
- CRDTs. Data structures designed so concurrent edits merge deterministically regardless of arrival order. Increasingly the practical choice, at the cost of extra metadata and memory.
None of these removes the need for judgement. A merge can be mathematically correct and semantically wrong — two people editing the same sentence in different directions produces a valid document that says something neither intended.
The commercial reason it stays rare
A subscription is easier to justify when the product stops working without it. Software that keeps functioning on your own machine has a weaker recurring-revenue story, and it complicates analytics, feature gating and server-side enforcement.
This is not a conspiracy; it is an incentive gradient. It does mean the architecture question is rarely decided on engineering grounds alone.
What to look for as a user
- Turn on airplane mode and open the app. What still works?
- Can you export everything in an open format, without a support request?
- Where does the data physically live, and can you back it up yourself?
- If the company disappeared tomorrow, what would you still have?
You will not always choose local-first, and you should not always want to — collaboration, search across large corpora, and anything requiring server-side computation have real reasons to be online. But knowing which you have chosen is worth the two minutes it takes to test.
Frequently asked questions
Is local-first the same as offline mode?
No. Offline mode is usually a limited cache bolted onto a cloud-first app, with reduced functionality and awkward reconciliation. Local-first means the device holds the authoritative copy in normal operation.
Does local-first mean my data is not backed up?
No — most local-first products sync to a server as well. The difference is that the server is a replica rather than the sole source of truth.
Is it less secure to keep data on my device?
It changes the threat model rather than worsening it. You take on device security, and you reduce exposure to a breach of the provider. Full-disk encryption and a strong device unlock cover most of the added risk.
