There’s a particular dread that comes from watching your cursor turn into a spinning rainbow wheel while you’re deep in a document. It’s not just the fear of losing work—though that’s part of it. It’s the sudden, vertiginous awareness that your thoughts have been living somewhere else this whole time. That the essay, the spreadsheet, the design file you’ve been pouring yourself into resides on a server in Ashburn or Dublin or somewhere in the Oregon desert, and your laptop is just a dumb terminal politely requesting access. When the connection drops, you remember: you don’t own this. You’re renting it.
For the better part of two decades, that arrangement has been the deal. Cloud-first was the gospel, and the gospel was good. It gave us collaboration, backups, and the freedom to work from any device. But a growing contingent of developers and designers are starting to ask whether we traded away something important in the process—and they’re building a new generation of software that insists your data should live on your machine first, and in the cloud only as an afterthought.
They call it local-first, and it might be the quietest revolution happening in software right now.
The cracks in the cloud
The cloud-first model has obvious virtues, but it also has costs that we’ve trained ourselves to ignore. When your application depends on a server to function, you’re subject to its moods. Airlines lose Wi-Fi at 35,000 feet. Subways are signal dead zones. Rural offices still exist. The promise of “work from anywhere” has always carried an asterisk: anywhere with reliable broadband.
But the deeper problem is ownership. When your data lives on someone else’s server, you’re at the mercy of their business model. Products get acquired and shuttered. Pricing changes overnight. Export features quietly disappear. Google Reader, Parse, Sunrise, Tasks’ older incarnations—graveyards full of tools people loved and trusted, until they weren’t there anymore.
There’s also a performance tax that cloud-first software exacts in small, accumulating ways. Every keystroke that waits for a server round-trip. Every click that triggers a loading spinner. The latency is usually measured in hundreds of milliseconds, which sounds trivial, but the difference between a tool that feels like an extension of your hands and one that feels like a remote control is profound. Local-first argues that software should be fast because it’s not asking for permission.
What local-first actually means
The term was given its clearest articulation in 2019 by a group of researchers and engineers led by Martin Kleppmann, the Cambridge computer scientist known for his work on distributed systems. They published what amounted to a manifesto titled “Local-first software: You own your data, in spite of the cloud,” and it laid out seven ideals that ranged from the philosophical to the deeply technical.
At its core, the argument is simple: your data should reside on your device, under your control, accessible without a network connection, and still capable of syncing across machines and collaborators when one is available. The challenge is doing that without the collaboration experience falling apart.
This is where the technology gets interesting, and where local-first stops being a romantic idea and starts being a real engineering proposition.
CRDTs and the end of “merge conflicts”
The technical problem is ancient: if two people edit the same document offline and then sync, what happens? Traditional approaches—Google Docs’ operational transformation, for instance—rely on a central server to sequence edits and maintain consistency. It works, but it requires the server to be the arbiter, which means it needs to be available.
Conflict-free Replicated Data Types, or CRDTs, take a different approach. They’re data structures mathematically designed so that any two copies can be merged automatically, regardless of the order in which edits arrive, without losing information and without a central authority. Every edit commutes. The math guarantees convergence.
“The idea that collaboration requires a central server is an artifact of our imagination, not a law of physics.” — Martin Kleppmann, from a talk on local-first principles
CRDTs have been around in academic circles since the 2010s, but they’ve only recently matured into something practical. Libraries like Automerge and Yjs have made it possible for ordinary developers to build real-time collaborative apps where the source of truth is the local device, and sync is just a background process.
The result is software that feels different. You can open a document on a flight, edit for three hours, land, and your changes sync the moment you connect—with no conflicts, no lost edits, no server intermediary. Multiple people can work on the same thing simultaneously, and the math handles the reconciliation invisibly.
The products leading the charge
You can see this philosophy spreading across the software landscape in ways both obvious and subtle:
- Obsidian built a devoted following by treating notes as plain Markdown files in a local folder. The app works completely offline. Sync is an optional paid add-on, not a dependency.
- Linear rethought issue tracking around a local-first sync engine that makes the app feel uncannily fast even when managing thousands of tickets. Its founders have been vocal about the architectural choice.
- Figma doesn’t use CRDTs—it relies on operational transforms—but its obsession with multiplayer performance and local caching pushed the industry toward a similar sensibility.
- Logseq and RemNote have embraced the same model for networked thought, prioritizing local storage and optional sync.
- Reflect and Tldraw are building note-taking and whiteboarding tools explicitly on CRDT foundations.
None of these are perfect implementations of the local-first ideal, and some compromise more than others. But they share a posture: the application serves you first and the network second.
Why it matters now
There’s a reason this movement is gaining traction at this particular moment. We’ve spent fifteen years centralized everything—our documents, our music, our photos, our task lists—and the costs are becoming harder to dismiss. Subscription fatigue is real. Privacy concerns have moved from the fringe to the mainstream. People are tired of their tools holding their work hostage.
But the deeper shift is cultural. We’re starting to remember that software used to belong to the people who used it. You bought a program, you installed it, it ran on your machine, and it was yours. The cloud convinced us to trade ownership for convenience, and for a long time that seemed like a fair deal. Local-first is the argument that we can have both—that the technical problems that forced us to centralize have been solved, and the only thing left is the will to build differently.
It won’t replace the cloud. There are entire categories of software—search, social, data-intensive computation—where centralized architectures are the only sensible option. But for the everyday tools where we think, write, plan, and organize our lives, local-first offers something radical: the idea that your work should belong to you even when the network is watching.
The rebellion isn’t loud. It’s files on your hard drive, a sync running quietly in the background, a cursor that moves without hesitation. But it’s real, and it’s growing. The next time your connection drops and your app keeps working as if nothing happened, you might find yourself wondering why it was ever supposed to work any other way.
