What the local-first movement gets right (and what it keeps getting wrong)

Local-first is the rare software idea that I find both completely obviously correct and annoyingly under-specified. The premise is: your data should live on your device, work offline, sync between your devices, and treat the server as a peer rather than a source of truth. If you have used Linear, or Apple Notes, or a recent Figma file, you have used something local-first, even if it isn’t branded that way.

The premise is correct. The implementation is harder than the talks make it sound.

What’s clearly right

The case for local-first, as a user experience posture, is closed. Apps that work offline are nicer than apps that don’t. Apps that don’t lose your work when the network blips are nicer than apps that do. Apps that don’t have a “loading” spinner for the file you opened two seconds ago are nicer than apps that do. These are not controversial claims. They are also not new claims — Roam, Workflowy, and the entire Bear-notes discourse have been making them for a decade. The local-first community just gave them a name and a research agenda.

What the research agenda got right, in particular, is the sync problem is a real problem. CRDTs exist. They work. They are not a magic wand — there is no CRDT that will resolve “user deleted the paragraph” and “user edited the paragraph” without a tiebreaker of some kind — but for the 80% case (collaborative text, shared lists, document metadata), they are good enough that “we don’t have a CRDT for this yet” is rarely the actual blocker.

The actual blocker, in 2026, is the same one it was in 2016: most teams can’t actually build the rest of the local-first system. The CRDT is the part with the papers. The schema migration, the storage engine, the access control, the conflict UI, the file import, the export, the device handoff, the “what happens when a device is offline for a month and rejoins” — these are the parts without papers, and they are 90% of the work.

What’s under-specified

The local-first conversation has, I think, three places where it tends to glide over things that are not actually settled.

Storage. “Local-first” generally means “SQLite on the device,” which is a fine answer for 2026 and was not a fine answer in 2018. The people who built local-first apps in the early days have war stories about IndexedDB and Core Data that I do not think have been fully absorbed into the literature. The CRDT papers assume a level of transactional substrate that is not always there.

Multi-writer schemas. Most local-first demos show a single shared document, or a list of documents where each document has one active editor. The harder case — multiple writers editing related records in a way that requires referential integrity — is not solved. You can fake it with last-writer-wins, and last-writer-wins is fine for some apps, but it is not fine for a CRM.

Auth and access control. The local-first mental model is, at heart, “the user owns the data.” That’s lovely for personal apps. It is very hard for team apps. The moment you have a workspace with five roles and three permission levels, the “server is a peer” framing starts to buckle. There are ways through this, but the ways-through mostly involve the server becoming a peer with veto power, which is not the same as the server being a peer.

What I’d love to see next

If I were, hypothetically, the program chair of a local-first conference, the talks I would be trying to schedule would not be about CRDTs. They would be:

• Postmortems from real teams. What broke, what got rolled back, what was harder than expected. The Wikipedia local-first section has 2,000 words on conflict-free replicated data types and 40 words on what to do when the user closes the laptop on a train and reopens it six hours later. The proportion should be reversed.

• The schema problem. A talk on what happens when you need to change a local-first schema, deployed across 200,000 devices, half of which are offline. This is the operational story that nobody wants to tell because it is scary.

• The “is this a team app?” talk. A serious, honest treatment of which app categories local-first is well-suited for and which it isn’t. The answer, I think, is “more than we used to think, fewer than the movement sometimes claims.” A lot of team apps would be better with offline support, but “offline support” and “local-first” are not the same thing, and conflating them does the movement a disservice.

The case for being excited anyway

Despite all of this, I am bullish. Not because the local-first community has solved the hard problems — they haven’t, and they would say so themselves — but because they have done the work of naming the hard problems. The CRDT papers are 30 years old. The local-first manifesto is five years old. Before the manifesto, “your app should work offline” was a feature request. After it, it’s a design constraint, and design constraints are how architecture decisions actually get made.

The next interesting chapter of this is going to be written by the teams who ship local-first apps at scale, hit the edge cases the papers don’t cover, and — crucially — write about it. The worst thing that can happen to this idea is that the production stories stay private.