“Works offline” is often treated like parsley on a product roadmap.
The main features are designed, pricing is decided, and the team spends two years attaching every action to a remote server. Then somebody asks, “Wouldn’t it be nice if this also worked on a plane?”
Offline mode is added to the backlog as though it were a small enhancement: some caching, a sync button, perhaps two arrows chasing each other in a circle. How difficult could it be?
Quite difficult, as it turns out.
Local-first is not merely the ability to open an application without an internet connection. It is an answer to two deeper questions: where does the authoritative copy of the data live, and who ultimately controls it?
That makes local-first less like a feature and more like a constitution. It can be changed later, but the process rarely feels like a minor patch.
Where does the real data live?
In a cloud-first product, the authoritative copy of the data lives on a server. The copy on your device is often temporary and subordinate. If a change has not reached the server, the system may treat it as a suspicious rumor.
A local-first product reverses that relationship. Changes happen against the local copy first. A server can still provide synchronization, backup, discovery, and collaboration, but it does not have to remain the sacred center that approves every keystroke.
The Ink & Switch essay that introduced the term described seven ideals: fast local response, multi-device access, optional networking, collaboration, long-term preservation, privacy by default, and ultimate user control.
Notice that “works offline” is only one item.
Offline access is the visible symptom. Ownership is the larger decision.
This distinction changes the product in ways users may never describe with architectural language but will immediately feel. Local interactions are fast. A network failure does not turn the interface into a museum of disabled buttons. A service outage does not make personal work temporarily fictional. The application can continue to exist as software rather than as a remote website wearing a desktop icon.
The cloud is not the enemy. It simply does not need to be the boss.
Local-first is sometimes interpreted as “shut down every server and carry files around on floppy disks.” That is unnecessarily theatrical.
Servers remain useful. They can synchronize devices, store encrypted backups, simplify sharing, and make online collaboration faster.
What changes is their role.
In a cloud-first model, the device serves the server.
In a local-first model, the server assists the devices.
That distinction determines what happens when the service has an outage, an account is suspended by mistake, or the company sends a very warm email explaining that it is “shifting strategic priorities.”
A local-first product should preserve its essential function when the server disappears. The user’s work is not based on the assumption that one company will remain operational forever. History has conducted several experiments on that assumption.
This does not mean every byte must remain on one machine. It means the user’s local state is not merely a disposable cache. The product can still sync through a server, peer-to-peer connection, local network, or even a file copied through some gloriously old-fashioned method. The architecture does not confuse one transport mechanism with ownership.
Synchronization is not magic
Sending a change from one device to another sounds easy. Things become more entertaining when two devices modify the same data while both are offline.
Conflict-free Replicated Data Types, or CRDTs, are data structures designed to merge concurrent changes from different replicas into a consistent result. Automerge is one practical implementation: it supports concurrent changes and automatic merging without requiring a central server to decide the order of every edit.
It is a remarkable area of engineering. It is also a reminder that the sentence “we’ll just merge the JSON” can contain an impressive amount of hidden suffering.
Text ordering, deletion, renaming, simultaneous edits, schema evolution, and partial synchronization all need explicit rules. Even mature collaborative systems can produce strange results when concurrent text is inserted at the same position. A 2025 paper on minimizing interleaving in collaborative text editing exists because two people typing at once can still create problems more interesting than either person intended.
Local-first does not mean synchronization has been solved.
It means the product is honest enough to place synchronization near the center of its architecture.
It also changes how failure is handled. In a central system, the server can reject a write. In a local-first system, the write may already have happened and reached other devices before a conflict becomes visible. The product needs a model for convergence, not merely a retry button.
Security is where the party really begins
Authorization is relatively straightforward in a centralized system. The server sees each request, checks a central source of truth, and decides whether the user is still allowed to perform it.
In a local-first system, a device may remain offline for weeks. During that time, the user’s access may have been revoked. When the device reconnects, what happens to the changes it created under its previous permissions?
If someone is no longer allowed to read a document, how do you remove the old copy from their device?
Usually, you do not.
Revocation, encryption-key distribution, device loss, deletion, and historical permissions become fundamental design problems. Ink & Switch’s Keyhive project explores ways to grant and revoke read, write, sync, and administrative capabilities without depending on a permanently available central authority.
Choosing local-first does not mean you have solved security.
It means you have purchased a more unusual collection of security problems.
That is not an argument against local-first. It is an argument against treating it as a cheerful offline checkbox. The decision affects identity, encryption, conflict resolution, backups, recovery, and the meaning of deletion. Those topics have a habit of becoming important shortly after somebody says, “We can figure that out later.”
Not every product should be local-first
A sympathetic idea is not automatically a universal architecture.
Some systems genuinely require central authority. Allowing a bank balance to be interpreted optimistically by four disconnected devices would create an exciting but short-lived financial product.
Large shared datasets, continuous centralized computation, strict regulatory controls, and transactions requiring a definitive global order may justify a cloud-first authority.
There are also products where local-first complexity offers little real benefit. If the application is useful only while connected to a live marketplace, public feed, or central operational system, pretending the network is optional may create more code than value.
The useful questions are:
- Must users continue working without a network?
- Is immediate local response essential?
- Should the core product survive a server shutdown?
- Must users be able to inspect, export, or move their data?
- Will multiple devices edit the same information?
- How should authorization work during long periods offline?
- Does the server need to be the authority, or can it merely help?
When most answers strongly favor independence, local-first deserves serious consideration.
Architecture is a promise
Users do not see the data architecture. There is no settings toggle labelled “ontological authority of your records,” and few people would enable it anyway.
They do experience the consequences.
Does the application respond immediately?
Does it work when connectivity disappears?
Can they export their files?
Can they access their own work after an account problem?
If the product vanishes, does their work vanish too?
A cloud-first product implicitly says:
You can continue working while my service remains available.
A local-first product makes a more demanding promise:
Even if this service disappears, the work you created remains yours.
That promise affects synchronization, security, storage, support, and the business model.
But that is what product decisions are for. We would not need the word “decision” if the purpose were simply to choose whatever is easiest.
Local-first is not a checkbox.
It is a decision about who the product ultimately belongs to.
Related reading
Sources and further reading
- Martin Kleppmann et al., Local-first software: You own your data, in spite of the cloud.
- Automerge, a CRDT library for local-first collaborative applications.
- Ink & Switch, Keyhive.
- Matthew Weidner and Martin Kleppmann, The Art of the Fugue: Minimizing Interleaving in Collaborative Text Editing.