The term "local-first" was formalized in a 2019 essay from Ink & Switch, a research lab, titled "Local-First Software: You Own Your Data, in Spite of the Cloud." The essay named a pattern that predates the term: software where the primary copy of your data lives on your own device, edits happen instantly against that local copy with no network round-trip required, and synchronization to other devices or collaborators happens in the background, opportunistically, without the app being unusable when it fails.
This is a different claim from "offline-first," a related but narrower idea that mostly concerns itself with the app still functioning without a network connection. Local-first is a stronger architectural commitment: even when the network is available and working perfectly, the local copy remains the one the app actually reads and writes against. The server is a sync relay, not a dependency.
The Technical Piece That Makes It Work: CRDTs
The hard problem local-first architecture has to solve is: if two devices each edit the same document while offline, and then reconnect, how do you merge those edits without a central server arbitrating who's right? The answer that made local-first practical for real collaborative apps is Conflict-free Replicated Data Types (CRDTs), a class of data structures with a mathematical guarantee: no matter what order updates arrive in, or how many devices were editing concurrently, every replica converges to the same final state without needing to ask a server to resolve the conflict.
CRDTs aren't new (the formal theory dates to a 2011 paper by Marc Shapiro and colleagues at INRIA), but production-quality libraries implementing them for real applications, Automerge and Yjs being the two most widely adopted, only matured enough for mainstream use in the last several years. They're what lets apps like collaborative note-taking and whiteboard tools sync edits between devices without a central authority deciding whose version wins.
What This Means for Privacy, Concretely
A cloud-first app has to receive your data in a form it can operate on: search it, index it, run features against it, serve it to other clients. That functional requirement creates a strong default pull toward storing your data in a form the server can read, because building search or collaboration features against opaque ciphertext is meaningfully harder engineering.
A local-first app doesn't have that pull, because the operations (search, edit, render) already happen on-device, against the local copy. The sync payload only needs to be readable by other instances of your own app on your own or collaborators' devices. That opens the door to encrypting the sync payload end-to-end, with the server relaying encrypted blobs it has no functional reason to decrypt, because decrypting them wouldn't unlock any feature the server needs to provide.
Local-first doesn't automatically mean encrypted or private. It's an architectural pattern, not a security guarantee. What it removes is the functional excuse for the server to read your data, since the server was never doing the reading, editing, or indexing to begin with. Whether a given local-first app actually encrypts its sync traffic is a separate decision the developers still have to make and you still have to verify.
The Trade-Offs Nobody Skips Past
Local-first architecture moves real complexity onto the client and onto you as the data owner, and it's worth being honest about where that lands. Multi-device sync becomes more involved to build correctly, since the app has to reconcile potentially divergent local states rather than simply fetching the current one from a server. Backup responsibility shifts toward the user or the app's local-backup design, since there's no single server copy that survives a lost or wiped device by default, only whatever synced elsewhere before the loss. Search and heavy computation across very large datasets can be genuinely harder on-device than server-side, where you can throw arbitrary compute at an index. And full-text search across encrypted local-first data specifically runs into the same hard problem searchable encryption research has been chipping away at for years: search over ciphertext without a trusted server to do the plaintext searching for you is not free.
| Property | Cloud-first default | Local-first default |
|---|---|---|
| Source of truth | Server | Device |
| Works with no network | Often broken or read-only | Fully functional |
| Server's functional need to read data | High (search, indexing, features) | Low (relay only) |
| Multi-device conflict handling | Server arbitrates | CRDT merge, no arbiter needed |
| Backup responsibility | Provider's server copy | Distributed across synced devices; user-managed |
Where This Shows Up Beyond Note-Taking Apps
Local-first thinking has spread past its original collaborative-editing use case into messaging and secure communication more broadly, for a reason that isn't a coincidence: an end-to-end encrypted messenger is, structurally, already a local-first system. Your device holds the plaintext message and the keys; the server, by design, only ever handles ciphertext it can't read. The MLS protocol (RFC 9420) for group messaging and the local-first CRDT work share a family resemblance: both are architectures built around the assumption that a central server shouldn't need to be trusted with the plaintext to do its job.
A local-first app and an end-to-end encrypted app arrive at the same shape from different starting problems, one solving for offline collaboration, the other for confidentiality. The overlap isn't an accident. Both are answers to "what's the least the server needs to see to still be useful."
Haven's message store follows this pattern for the same reason: message content and keys live on your device, and what reaches the server is ciphertext the server has no functional need, and in the end-to-end path no technical ability, to read. It's the same design instinct the local-first movement named for documents and notes, applied to messaging, where the stakes for getting the server's access boundary right are considerably higher.