Local-First Software Is Having a Moment

Local-first software keeps the authoritative copy of your data on your own device. The app reads and writes locally — so it’s fast and works fully offline — and synchronization with your other devices and collaborators happens in the background, whenever a connection exists. The cloud doesn’t disappear; it gets demoted from “the place the app lives” to a sync-and-backup layer.

That inversion is the whole idea, and it’s stricter than it sounds. Plenty of apps tolerate a dropped connection. Very few treat the local copy as the source of truth.

Local-first vs cloud-first vs offline-tolerant

A cloud-first app is a window onto a server. The server owns the data, every meaningful action is a network request, and when the connection drops, the window goes dark.

An offline-tolerant app caches data for reading and queues writes to replay later, but the server still arbitrates every change. Conflicts surface as sync errors or “keep mine / keep theirs” dialogs, because the design never decided what a merge actually means.

A local-first app inverts the hierarchy: every device holds a full working replica it may write to at any time, and merging concurrent edits is designed into the data model itself.

	Cloud-first	Offline-tolerant	Local-first
Source of truth	Server	Server	Your device
Offline	Broken or read-only	Cached reads, queued writes	Fully functional
Conflicts	Server serializes writes	Errors and dialogs	Merged automatically
Server’s role	Runs the app	Runs the app, forgives gaps	Sync, backup, sharing

Where did the term come from?

The name comes from a 2019 essay by the research lab Ink & Switch — “Local-first software: You own your data, in spite of the cloud” — written by Martin Kleppmann and colleagues. It laid out seven ideals: instant response, data available on every device, a network that’s optional, seamless collaboration, work that stays readable for decades, security and privacy by default, and ultimate user ownership. Its core argument was that cloud apps traded ownership and longevity for collaboration — and that newer data structures meant we no longer had to choose.

CRDTs in plain English

The technology behind that claim is the CRDT — conflict-free replicated data type. A CRDT is a data structure with one defining guarantee: replicas that have seen the same set of changes arrive at the same state, regardless of the order those changes arrived in, with no central arbiter picking winners. Merging isn’t an error path; it’s the structure’s ordinary behavior.

A concrete example. A shared grocery list lives on two phones, both offline:

• Phone A adds coffee and checks off milk.
• Phone B adds lemons and renames bread to sourdough.

When both come back online, they exchange changes and each applies the other’s. Both converge on the identical list — coffee and lemons added, milk checked, sourdough renamed — with nothing to ask the user, because every item carries a stable ID and every edit carries metadata (think logical timestamps) that the merge rules consume deterministically.

When two edits genuinely collide — both phones rename the same item — the type’s rule picks an outcome, commonly “last writer wins” by logical time. The winner isn’t guaranteed to be the one you’d have chosen; the guarantee is that every replica picks the same one without asking a server. Under the hood, CRDT state usually looks like a JSON-shaped tree annotated with IDs and counters — larger than the raw data, which is part of the cost.

Sync engines, the emerging middle layer

A CRDT answers “how do concurrent edits merge.” Shipping an app requires answers to everything around that: persisting changes, streaming them over a WebSocket or server-sent events, replicating only the slice of data a device needs, and feeding updates reactively into the UI. That bundle — a sync engine — is emerging as its own layer of the stack, sitting between the interface and the local store much as an ORM sits between an app and its SQL or NoSQL database.

It rhymes with the broader push to move data closer to users — the same instinct behind edge databases — carried to its endpoint. The closest edge is the device itself.

The pattern in the wild

• Figma’s multiplayer applies your edits locally and immediately, while a server merges property-level changes from all participants — an architecture its engineers described as CRDT-inspired, tuned for design files.
• Linear built its product on a sync engine: the client keeps a local copy of your workspace, the UI reads and writes that copy directly, and deltas stream in the background. It’s why interactions feel instant.
• Obsidian is local-first in the plainest sense: your notes are Markdown files in a folder on your disk, the app is fully functional with no account at all, and sync is an optional layer on top.

These are not identical architectures, which reflects the honest state of local-first: a set of principles with several competing implementations.

Why interest grew

• Ownership. Every service shutdown that strands user data makes “the primary copy is yours” more persuasive.
• Latency. No round trip beats any round trip; local reads and writes make apps feel instant everywhere on the planet.
• Resilience. Planes, tunnels, and outages stop being app-breaking events.
• Collaboration, nearly free. The machinery that merges two offline edits is the same machinery that powers live multiplayer — one investment, two features.

The honest tradeoffs

• Rich text is hard. Merging two rewrites of the same sentence can be deterministic and still read like nonsense. Text CRDTs remain the most active, least settled corner of the field.
• Auth and permissions get awkward. When merges happen on devices, a server-side check is no longer the single gate deciding who may change what.
• Storage is finite. A full replica of a large workspace may not fit on every device, browser storage quotas are real, and partial replication reopens hard questions.
• The server never really leaves. Sharing links, onboarding a new device, backup, and cross-workspace search all want an always-on peer in practice.

The takeaway

Local-first means the copy on your device is the real one: the app works completely offline, and sync is background machinery rather than a prerequisite. CRDTs make that machinery trustworthy by guaranteeing every replica merges concurrent edits to the same result, and sync engines are packaging the remaining plumbing into a reusable layer. The tradeoffs — messy rich-text merges, harder permissions, finite storage — are real but increasingly well mapped. The cloud isn’t going away; for a growing class of apps, it’s just being reassigned.