Ever wondered how your collaborative apps work when you're offline, or when the internet connection drops at the worst possible moment? The seamless editing experience you expect updating documents on different devices, even with no Wi-Fi isn't simple to achieve. For years, the standard approach resulted in frustrating merge conflicts and lost work, but a decade of work by Martin Kleppmann is changing that.
That moment, that specific, infuriating failure, is what Martin Kleppmann has spent more than a decade trying to eliminate.
Kleppmann is an Associate Professor at the University of Cambridge, a two-time startup founder whose companies were acquired by LinkedIn and Red Gate Software, and the author of the widely-read O'Reilly book Designing Data-Intensive Applications. But the work that now reaches into millions of devices began as something much smaller: a research question about what happens when computers disagree.
The answer, it turns out, depends entirely on how you structure the data.
Where It Started: Cambridge, Distributed Systems, and the Problem with Central Servers
Kleppmann's academic home is the University of Cambridge, where he teaches Concurrent and Distributed Systems alongside Cryptography and Protocol Engineering. Before the academic chapter, he was a software engineer and startup founder co-founding Rapportive, which LinkedIn acquired in 2012, and Go Test It, acquired by Red Gate Software in 2009.
That blend of production engineering and theoretical rigor shows up everywhere in his work. He is not content to describe a problem in the abstract. He wants to solve it, prove the solution correct, and ship it so others can build on top of it.
"Martin has been exploring local-first software and CRDTs for over 10 years," notes the Local-First.fm podcast, "which has led to the creation of Automerge."
The Local-First.fm episode #4 featuring Kleppmann traces the intellectual path from that early research to the library developers now use in production applications. It is one of the most complete public records of how the ideas evolved and why Kleppmann believes the conventional cloud-first model of application architecture is, in the long run, the wrong default.
The Original Essay: Local-First Software and the Problem with the Cloud
The term "local-first" was introduced by Kleppmann and colleagues at Ink & Switch in their 2019 essay, "Local-first software: You own your data, in spite of the cloud." The essay described software that prioritizes local data storage and peer-to-peer synchronization over cloud-centric architectures. Seven years later, in early 2026, a Verity Research report on local-first software observed that the ideas had moved "from academic curiosity to production reality."
The core argument is elegant. Cloud-first applications treat your device as a dumb terminal that exists only to connect to a central server. Every edit flows up to the server, which acts as the source of truth, and then flows back down to every other device. This model is simple to reason about. It is also fragile. The server goes down, and no one can work. The network drops on a flight, and the app becomes a decorative brick. The company changes its pricing, and years of user data sit behind a new paywall.
Local-first software inverts this. The primary copy of user data lives on the device itself. Changes are made locally, instantly, with full functionality no round-trip to a remote server required. When connectivity is available, changes synchronize between devices. When it is not, work continues uninterrupted.
"Local-first software keeps the primary copy of user data on their own devices, enabling offline use, instant interactions, and long-term data ownership," the Verity Research report explains. The report, published in February 2026, surveys how CRDTs have matured, how SQLite-based sync engines have emerged, and how platform-level adoption from Apple and Google is now driving the approach into mainstream mobile development.
What CRDTs Actually Do: The Math Behind the Magic
Conflict-free Replicated Data Types CRDTs are the specific data structures that make local-first possible at scale. The definition, as the CRDT Papers reference site frames it, is straightforward: CRDTs allow multiple users or devices to edit shared data concurrently and merge changes automatically, without a central server to coordinate. That sounds almost too simple to be useful. The power is in the details.
The math behind CRDTs ensures that no matter how edits are ordered no matter which device syncs first, which edits arrive last, which conflicts seem to overlap every participant in the system converges on the same final state. There is no data loss. There is no arbitrary "last write wins" rule that silently discards someone's work. There is no need for a lock that blocks all other users while one person edits.
Kleppmann's own research contributions to the CRDT field are ongoing. In April 2024, he co-authored two papers presented at the 11th Workshop on Principles and Practice of Consistency for Distributed Data: "Undo and redo support for replicated registers" and "Extending JSON CRDTs with move operations." Both papers address practical limitations that arise when CRDTs meet real-world editing workflows. Undo, in particular, is deceptively hard in a distributed system if User A makes a change that User B then builds upon, should User A be able to undo that original change, and if so, what happens to User B's dependent edits?
The CRDT Papers listing documents a vibrant and growing academic literature, with Kleppmann's recent work occupying the "undo" and "JSON" keyword clusters precisely the areas that matter most for application developers working with structured document data more than raw registers.
Automerge: The Library That Made the Theory Real
Automerge is the open-source implementation that grew out of Kleppmann's research. It is, in the words of the Automerge project's own site, "a local-first sync engine for multiplayer apps that works offline, prevents conflicts, and runs fast."
The project's ambitions are substantial. Automerge aims to be version control for your data not just the document you are working on, but the entire state of an application. Multiple users, multiple cursors, multiple devices one document. The system remembers every change. You can branch fearlessly and experiment boldly, because your document's entire history lives locally, ready when you need it.
Version 3.0, released in late 2025, marked a significant milestone. The release introduced a columnar storage format that reduced document sizes by 40-60 percent compared to Automerge 2.x. It shipped a new sync protocol that achieves sub-millisecond merge times for typical document sizes. The core was rewritten in Rust, with bindings for JavaScript, Swift, and Kotlin. A built-in presence and awareness protocol lets applications show who else is currently viewing or editing a document. And document branching and merge git-like workflows for data entered the feature set.
The Automerge team is small but deep. "For more than a decade, Automerge has been an independent open source project built by a serious, dedicated team of engineers and computer scientists," the project site notes. "That team includes production engineers who co-founded Heroku, and computer scientists like renowned Cambridge professor Martin Kleppmann." The ongoing effort is supported by Ink & Switch, an industrial research lab that provides a baseline of full-time engineering staff, including lead maintainer Alex Good and Orion Henry.
The team's stated philosophy is worth quoting directly: "We plan for the long-term, and think about where the project will be in a decade, not how to get through the next funding round. We are driven to build high performance, reliable software you can bet your project on. We develop rigorous academic proofs of our designs using theorem proving tools like Isabelle, and implement them using cutting edge performance techniques adopted from the database world. Our standard is to be both fast and correct."
That last sentence our standard is to be both fast and correct captures something important about the Kleppmann approach. Academic computer science and production software engineering are often portrayed as separate worlds with separate values. Kleppmann insists on holding both at once.
How Bluesky Became a Real-World Test Case
One of the most visible production deployments of local-first principles is Bluesky, the social networking platform. The connection between Kleppmann and Bluesky runs through the Local-First.fm episode #4, where the conversation explores how generic sync servers and the impact this technology could have on local-first software in the future.
Bluesky's architecture treats user data as something users own and control, with synchronization happening between devices more than through a single authoritative server. The platform's use of CRDT-based approaches means that when users make overlapping edits whether posting, replying, or reorganizing their feeds the system converges cleanly without losing content.
For ReadySyncGo readers building mobile workflows, the Bluesky example is instructive. Social applications were among the first to face the offline-editing problem at scale, because users expect to scroll, post, and reply regardless of whether their phone has a signal. But the same pattern applies to any collaborative mobile workflow: field inspections, inventory management, shared task lists, inspection reports, customer relationship notes.
The AI Connection: Conflict Resolution Scales to Human-Machine Collaboration
In an April 2026 episode of Software Engineering Radio (SE Radio 716), Kleppmann discussed local-first software with host Adi Narayan, covering what the term means, how it leads to simpler application architectures compared to the cloud-first model, and the benefits to developers and users from keeping all of their data on their own devices.
The conversation turned to a question that is becoming increasingly urgent: what happens when AI agents begin editing the same documents as humans? Kleppmann's answer connects directly to the CRDT math. If an AI makes an edit and a human makes a competing edit, the same conflict-resolution rules that handle two humans editing simultaneously can handle a human and an AI. The system converges. No special case is required.
"In the context of AI, they discuss vibe coding, local-first apps, and how the conflict-resolution work that enables data to be synchronized between users can also work with human-AI collaboration," the SE Radio show notes observe.
For ReadySyncGo readers working on automation tools, this is not an abstract research question. If your workflow involves AI agents making decisions, writing content, or updating records and then humans reviewing, editing, or overriding those changes you are dealing with concurrent editing at the data layer. CRDT-based sync engines handle that problem generically, which means you do not have to build bespoke conflict-resolution logic for every AI-human interaction in your application.
The Ecosystem in 2026: Automerge, Yjs, SQLite Sync, and the Path Forward
The Verity Research report from February 2026 surveys the current local-first landscape with useful precision. Two CRDT implementations dominate the ecosystem: Automerge 3.0 and Yjs. The report provides a comparison that is practical for developers making tool selection decisions.
Automerge's JSON-like nested data model maps naturally to complex application state, making it well-suited for rich-text collaboration and nested documents. Yjs, by contrast, uses shared types (Map, Array, Text, XML) and remains the most widely deployed CRDT library, powering collaborative editing in tools like Notion, Tiptap, and BlockNote. Yjs's relative encoding strategy is memory-efficient for real-time collaboration, though it trades off some of Automerge's richer data model capabilities.
Perhaps the most significant shift in local-first architecture, the Verity Research report notes, is the convergence on SQLite as the application database, paired with sync engines that replicate changes between SQLite instances. Tools like cr-sqlite, created by Matt Wonlaw, add CRDT semantics directly to SQLite tables. This convergence matters for ReadySyncGo readers because SQLite is already the dominant mobile database the sync layer is being folded into the same storage engine that powers most mobile applications.
Why This Matters for ReadySyncGo Readers
ReadySyncGo covers data sync, mobile workflows, and automation tools and the CRDT revolution that Kleppmann helped originate is directly relevant to all three.
For data sync, CRDTs represent the first principled solution to the offline merge problem that has plagued distributed applications since the early days of mobile computing. The traditional approach optimistic locking, last-write-wins, or manual conflict resolution all have failure modes that CRDTs mathematically eliminate. When you are building a sync layer for a mobile app, you are essentially choosing which class of bugs you are willing to accept. CRDTs shrink that acceptable-bug surface dramatically.
For mobile workflows, the local-first model changes the reliability assumptions that shape application design. Cloud-first apps treat the network as the happy path and offline mode as a degraded fallback. Local-first apps treat local operation as the happy path and server synchronization as a convenient enhancement. The difference in user experience is profound, and the difference in code complexity is surprisingly small once you adopt a CRDT-based sync engine.
For automation tools, the human-AI collaboration question Kleppmann addressed on SE Radio 716 points toward a future where your automation layer is not just executing tasks but editing shared state alongside human users. CRDTs provide the conflict-resolution substrate that makes that collaboration safe and predictable.
From Cambridge to Your Device: A Reading Map
Kleppmann's work spans academic papers, open-source software, a widely-read book, conference talks, and an active public presence. For readers who want to go deeper, the entry points are well-organized.
The essential starting point is the Local-First.fm episode #4, which walks through the intellectual history and practical details of Automerge in Kleppmann's own voice. It is conversational, technical, and patient the way a good lecture works when the lecturer genuinely loves the subject.
The SE Radio 716 episode from April 2026 covers the broader architecture story with more emphasis on developer benefits and the AI connection. It is a good second listen.
The Verity Research report on local-first software in 2026 provides a snapshot of the production ecosystem as it stands in early 2026 useful for understanding which tools have matured, which trade-offs are documented, and where the tooling gaps remain.
For the academic papers, the CRDT Papers reference site at crdt.tech is the definitive bibliography, including Kleppmann's 2024 work on undo/redo and move operations in JSON CRDTs.
And Kleppmann's personal website lists recent conference talks including a March 2026 appearance at QCon London and a February 2026 talk at the Local First (LoFi) meetup alongside blog posts on distributed systems verification and a running record of his research directions.
What Comes Next
The local-first movement is no longer waiting for adoption. It is managing it. The Verity Research report from February 2026 identifies platform-level support from Apple and Google as a key driver when the operating system vendors begin building sync primitives that assume local-first more than cloud-first, the ecosystem shifts. Application developers get better guarantees for free. Users get more reliable apps.
Kleppmann's specific contributions the CRDT research, the Automerge library, the 2019 essay that named the movement represent one of the cleaner cases in modern software where theory, implementation, and community adoption lined up over a decade more than emerging all at once. That patience, that willingness to spend ten years on a problem before the world caught up, is itself part of the story.
If you are building mobile workflows, sync layers, or automation tools in 2026, the CRDT-based local-first stack is no longer a research curiosity. It is production software with a decade of hardening, an active open-source team, and a growing body of evidence that it solves problems the old architecture cannot. Kleppmann built the foundation. The building is yours.