The problem it answers
The idea comes from a 2019 essay by Martin Kleppmann, Adam Wiggins, Peter van Hardenberg and Mark McGranaghan at the research lab Ink & Switch. They started from a trade-off that people who make things live with every day.
Cloud apps such as Google Docs and Trello make real-time collaboration easy and let people reach their work from any device. But all data access goes through the vendor’s server. If the service is unavailable, the software cannot be used; if it shuts down, the software stops working and the work may be lost with it. Older desktop apps that read and write files on the local disk have the opposite profile: full ownership, no dependence on anyone’s server, but awkward collaboration and no easy access across devices.
The essay’s summary is that the cloud gives us collaboration, while old-fashioned apps give us ownership. Local-first software is its proposal for getting both.
The core idea: swap the roles
In a cloud app, the copy on the server is primary and authoritative, and any copy on a device is a cache. A change that has not reached the server, in the essay’s words, “didn’t happen”.
Local-first apps swap those roles. The copy on the person’s laptop, tablet or phone is the primary copy. Servers still exist, but they hold secondary copies to help with access from several devices. What “the device is the source of truth” means looks at that shift in detail.
Because the primary copy is local, reading and writing never wait for a network round trip, and the app keeps working with no connection. Changes sync with other devices in the background when a path is available.
The essay sets out seven ideals that follow from this, from responsiveness and offline use to privacy, longevity and user control. The seven ideals of local-first software walks through each one. For how local-first differs from building an app offline-first, see offline-first vs local-first.
How it is built
The hard part is letting several copies change independently and still agree. The essay points to conflict-free replicated data types (CRDTs) as a promising foundation. CRDTs emerged from research in 2011. They are general-purpose data structures, like maps and lists, designed so that copies edited apart can be merged automatically into the same result. How CRDTs merge changes explains the mechanism.
Two properties make CRDTs a good fit:
- They do not care how changes travel. The essay notes that CRDTs can sync through a server, over a peer-to-peer connection, by Bluetooth between nearby devices, or even on a USB stick.
- They are multi-user from the ground up. An app can swap its ordinary data structures for CRDT versions and have concurrent edits merged for it. The essay notes one case a CRDT cannot settle alone: two people changing the same property of the same object, where it keeps both values for the app or the user to resolve.
Ink & Switch built an open-source CRDT library, Automerge, while researching the idea. Its README describes the aim as supporting local-first applications the way relational databases support server applications.
What the prototypes showed
The essay reports on several prototypes built on these ideas, and its findings are candid about both sides.
What worked: the CRDT library was reliable, offline work felt good because the apps simply kept working regardless of network status, and conflicts turned up less than the team had feared, partly because people tend to avoid editing the same thing at the same moment.
What did not: CRDTs keep their full change history, which caused performance, memory and disk problems with real documents. Getting changes between devices remained unsolved, since CRDTs only define how data merges, not how it arrives. And peer-to-peer systems were never simply online or offline, which made it hard for people to reason about which version they were seeing.
Servers still have a place
Local-first is not the absence of servers. The essay describes them as cloud peers that support apps without sitting on the critical path. A server can store a copy of a document and forward it to devices that come online later, which solves the case where two collaborators are never online together. It can also be a backup location, a bridge to traditional server APIs, or a source of extra computing power.
The essay sums up the difference this way: the key change in local-first systems is not an absence of servers but a change in their responsibilities. They play a supporting role, and are not the source of truth.
Where it fits
The essay is explicit about scope. It addresses apps for creating documents and files, and personal data such as notes, calendars, to-do lists and password managers. It does not argue for rebuilding banking, e-commerce, social networking or ride-sharing this way; it says those are well served by centralised systems.
For apps in between, the practical route is incremental. The essay suggests trusting the local cache by default, testing with the network turned off, making clear when data stays on the device and when it goes to a backend, and offering exports in standard formats such as JSON or PDF.