I lost two hours of work last Tuesday because my internet went down for eleven minutes.
Not because I was using some exotic cloud-dependent tool. I was editing a document in a mainstream SaaS product. The kind with a billion-dollar valuation and a “works offline” checkbox somewhere in their marketing materials. When my connection dropped, the app froze. When it came back, my changes were gone. The conflict resolution had decided that the empty server state was more recent than my local edits.
Eleven minutes of downtime. Two hours of work. And a growing suspicion that maybe the way we build software has a fundamental problem.
I am not the only one thinking this. Local-first software, a paradigm where your data lives on your device first and syncs to the cloud second, has been gaining serious momentum throughout 2026. FOSDEM dedicated an entire developer room to local-first, CRDTs, and sync engines this year. Companies like Linear and Figma have proven that local-first principles can power products used by millions. And the developer tooling has finally matured to the point where you do not need a PhD in distributed systems to build this way.
Here is what local-first actually means, why it matters now, and how to start building with it.
What Local-First Actually Means
The term “local-first” comes from a 2019 research paper by Ink & Switch, a lab focused on the future of computing. Their definition is straightforward: local-first software keeps a full copy of your data on your device. The cloud exists for sync and backup, not as the source of truth.
This is not the same as “offline mode.” Most apps treat offline as a degraded state. You get a warning banner. Some features stop working. When you reconnect, the app tries to reconcile what happened while you were offline, and sometimes it gets that reconciliation wrong.
Local-first flips this entirely. Your device is the primary. Reads and writes happen locally, instantly, with zero network latency. The network is secondary. When it is available, your changes sync to other devices and to a server. When it is not, you keep working normally. There is no degraded state because local is the default state.
The seven principles from the original Ink & Switch paper still hold:
-
No spinners. Operations happen locally, so they feel instant.
-
Your data is yours. It lives on your device in a format you control.
-
The network is optional. Everything works offline. Sync happens when possible.
-
Collaboration works. Multiple people can edit the same data, and conflicts resolve automatically.
-
Data outlives the software. Your data is stored in open formats, not locked in a proprietary cloud.
-
Security and privacy by default. Data does not have to leave your device unless you choose to share it.
-
Full user control. You decide where your data goes and who can access it.
If this sounds idealistic, consider that some of the most successful products of the past few years already follow these principles. Figma handles real-time collaboration with local-first techniques under the hood. Linear stores data locally and syncs in the background. Obsidian keeps everything as plain Markdown files on your machine. These are not niche experiments. They are products that millions of developers and designers use daily.
Why Local-First Is Gaining Ground in 2026
Three things have converged to make local-first practical this year in ways it was not before.
Cloud Fatigue Is Real
The cloud solved enormous problems. It also created new ones. Monthly SaaS bills that compound across dozens of tools. Vendor lock-in that makes switching feel impossible. Outages that take down your entire workflow because a server in Virginia had a bad day. And a growing awareness, especially in Europe with stricter data regulations, that sending every keystroke to someone else’s computer is not always a great idea.
Developers are feeling this acutely. If you are building a product and every feature requires a round trip to a server, your infrastructure costs scale linearly with usage. If you are building local-first, most computation happens on the user’s device. Your server costs drop dramatically because the server is doing sync, not processing.
The Tooling Has Matured
Two years ago, building a local-first app meant rolling your own sync layer. You needed deep knowledge of distributed systems, conflict resolution, and data replication. The developer experience was rough.
That has changed. Tools like PowerSync, ElectricSQL, Zero, and Triplit have turned what used to be a research project into a framework you can npm install. The abstractions are solid. The documentation is real. You can build a local-first app today with the same level of effort as building a traditional client-server app.
Users Expect Instant
We have trained users to expect instant responses. Every major app invests heavily in perceived performance. Skeleton screens, optimistic updates, background prefetching. All of these are workarounds for the fundamental latency of client-server architecture.
Local-first eliminates the need for these workarounds. When your reads and writes happen locally, the UI is genuinely instant. Not “feels instant because we show a skeleton.” Actually instant. Zero milliseconds of latency for every interaction. Users notice the difference even if they cannot articulate why the app “feels fast.”
CRDTs: The Technology That Makes It Work
The hardest problem in local-first is this: if two people edit the same data on different devices while offline, what happens when they reconnect?
Traditional databases solve this with locks or “last write wins.” One person’s changes overwrite the other’s. That is fine for a banking system where you want strict ordering. It is terrible for a collaborative document where both people’s changes matter.
Conflict-free Replicated Data Types, or CRDTs, solve this differently. They are data structures designed from the ground up to handle concurrent edits without conflicts. The math guarantees that no matter what order updates are received, every device eventually converges on the same state. No conflicts. No data loss. No central server needed to mediate.
Here is the simplest way to think about it. Imagine two people have a shared shopping list. Person A adds “milk” while offline. Person B adds “eggs” while offline. When they reconnect, a CRDT-based list will have both “milk” and “eggs.” Neither change is lost, and no conflict resolution was needed. The data structure itself handles it.
This works for more complex scenarios too. CRDT implementations exist for text documents (collaborative editing like Google Docs), JSON-like objects (application state), counters, sets, maps, and more. Libraries like Automerge and Yjs have been battle-tested in production for years and handle edge cases that would take months to solve from scratch.
The practical implication for you as a developer: you do not need to understand the mathematics behind CRDTs to use them. The libraries abstract the complexity. You interact with what feels like a normal JavaScript object, and the sync layer handles replication and conflict resolution behind the scenes.
const repo = new Repo({
network: [new BrowserWebSocketClientAdapter('wss://sync.example.com')],
})
// Create a document that syncs automatically
const handle = repo.create({ items: [], title: 'Shopping List' })
// Local changes sync to all connected peers
handle.change((doc) => {
doc.items.push({ name: 'milk', added: Date.now() })
})
That is it. You create a document, make changes locally, and the library handles syncing those changes to every connected device. No manual conflict resolution. No server-side merge logic. The CRDT guarantees convergence.
The Current Tool Landscape
The local-first ecosystem in 2026 has matured significantly. Here are the tools worth knowing about, organized by what they do best.
Sync Engines (Bring Your Own Backend)
PowerSync is the most production-ready option if you have an existing Postgres, MongoDB, or MySQL database. It syncs a subset of your server data to a local SQLite database on the client. Your backend stays the same. You add PowerSync as a sync layer between your existing database and your frontend. This is the lowest-friction path for teams migrating an existing app toward local-first.
ElectricSQL takes a similar approach but focuses specifically on Postgres. It provides active-active sync between your Postgres database and SQLite on the client. If your stack is already Postgres-based, ElectricSQL gives you local-first capabilities without changing your data model.
Full-Stack Local-First Frameworks
Zero and Triplit are designed for building collaborative apps from scratch. They handle the entire stack: local storage, sync, conflict resolution, and real-time updates. If you are building something like a Notion clone or a project management tool, these frameworks give you multiplayer collaboration out of the box.
Jazz takes an opinionated approach to local-first, providing a framework where collaborative data structures are the foundation of your app. It is particularly good for apps where real-time collaboration is a core feature, not an afterthought.
CRDT Libraries
Automerge is the gold standard for document-level CRDTs. It handles complex nested data structures and has excellent support for undo/redo, branching, and merging. If you are building something with rich, structured data (think: a collaborative spreadsheet or design tool), Automerge gives you the most flexibility.
Yjs is the go-to for text editing. It powers the real-time collaboration in many popular editors and has a massive ecosystem of bindings for frameworks like ProseMirror, TipTap, CodeMirror, and Monaco. If your app involves collaborative text editing, Yjs is likely the right choice.
Local Databases
SQLite (via wa-sqlite or better-sqlite3) is the local database that powers most of these solutions. Running SQLite in the browser via WebAssembly has become reliable and performant. On mobile and desktop (Electron, Tauri), native SQLite gives you a proper relational database on the user’s device.
RxDB provides a reactive, local-first database with built-in replication to any backend. It is framework-agnostic and works across browser, Node.js, React Native, and Electron.
When Local-First Makes Sense (and When It Does Not)
Local-first is not the right architecture for everything. Here is a practical framework for deciding.
Local-First Is a Strong Fit When:
Your app handles user-generated content. Note-taking apps, design tools, writing tools, project management, personal databases. Anything where the user creates and owns data benefits enormously from local-first. The data belongs to the user conceptually, so it makes sense for it to live on their device.
Offline capability matters. Field service apps, mobile apps used in areas with poor connectivity, tools for travelers. If your users cannot always count on a stable internet connection, local-first gives them a seamless experience regardless.
Real-time collaboration is a core feature. CRDTs were designed for exactly this. If multiple people need to edit the same data simultaneously, local-first with CRDTs gives you collaboration that works even when participants are intermittently offline.
You want to reduce server costs. When most computation happens on the client, your server does sync and backup rather than processing every request. This can dramatically reduce infrastructure costs, especially for apps with many concurrent users. For indie hackers and solo founders watching their SaaS costs, this matters.
Local-First Is Not Ideal When:
You need a single source of truth with strict consistency. Financial transactions, inventory systems, booking platforms. Anything where two people should not be able to “claim” the same resource simultaneously. CRDTs provide eventual consistency, not strong consistency.
Your data is primarily server-generated. Analytics dashboards, news feeds, search engines. If the server produces the data and the client just displays it, local-first adds complexity without much benefit.
Your app depends on real-time server-side processing. Live video streaming, multiplayer gaming with server authority, real-time bidding. These need a server in the loop for every interaction.
Regulatory requirements mandate server-side control. Some industries require that data be stored and processed on controlled servers. Local-first can complicate compliance in these cases.
Getting Started: A Practical Path
If you want to try local-first without rewriting your entire app, here is a pragmatic approach.
Start with One Feature
Pick a feature in your app where offline capability would genuinely improve the experience. A note editor, a task list, a settings panel. Something self-contained.
Build that one feature with a local-first approach. Use PowerSync or ElectricSQL to sync it with your existing database. Keep everything else the same. This gives you real experience with the paradigm without a risky full rewrite.
Choose Your Sync Strategy
The biggest architectural decision is how data moves between devices. You have three main options:
Server-mediated sync is the most familiar. Clients sync through your server. The server stores the canonical copy and mediates sync between devices. This is what PowerSync and ElectricSQL do. It is the easiest to reason about and fits naturally with existing backend architectures.
Peer-to-peer sync removes the server from the sync path. Devices communicate directly, often using WebRTC. This gives you true decentralization but adds complexity around discovery (how do devices find each other?) and availability (what if the peer you need to sync with is offline?).
Hybrid combines both. Sync through a server when available, fall back to peer-to-peer when not. This gives you the reliability of server-mediated sync with the resilience of P2P. Most production local-first apps end up here.
Handle the Hard Parts
Two things trip up developers new to local-first:
Schema changes. When your data model evolves, you need to handle migrations on every client device, not just on the server. Plan for this from the start. Use versioned schemas and write migration logic that runs locally.
Authorization. In a traditional app, the server checks permissions on every request. In a local-first app, the data is already on the client before the server can say no. You need to think about authorization differently. Typically, the sync layer handles this by controlling which data subsets sync to which clients.
What This Means for the Future of Web Development
I have been watching the JavaScript ecosystem evolve for years, and local-first feels like one of the more significant shifts. Not because it replaces everything, but because it changes the default assumption.
For a decade, the default assumption was: data lives on the server, the client asks for it. Local-first flips that to: data lives on the client, the server helps distribute it.
This is not theoretical. It changes how you think about building products. You stop worrying about API latency because there is no API call for local reads. You stop worrying about loading states because the data is already there. You stop worrying about offline because offline is just the normal state with sync paused.
The ecosystem is still young compared to traditional client-server tooling. You will hit rough edges. Documentation sometimes assumes distributed systems knowledge. Some tools are better suited for greenfield projects than migrations. But the trajectory is clear. Every major sync engine and CRDT library shipped significant improvements in the first quarter of 2026 alone.
If you are building a new product this year, especially anything involving user-generated content or collaboration, local-first deserves serious consideration. The tools are ready. The developer experience is good. And your users will notice the difference the first time they lose internet and your app keeps working like nothing happened.
Resources to Go Deeper
If you want to explore further, here are the starting points I found most useful:
The original Ink & Switch paper (“Local-First Software: You Own Your Data, in Spite of the Cloud”) is still the best introduction to the philosophy. It is long but worth reading in full.
lofi.so maintains a directory of local-first projects, tools, and frameworks. It is the most comprehensive catalog of the ecosystem.
The FOSDEM 2026 Local-First track recordings cover everything from beginner introductions to advanced CRDT implementations. The talks on sync engine internals are particularly good if you want to understand what these tools do under the hood.
And if you want to see local-first in action, clone one of the example apps from Automerge, Yjs, or Zero. Build a simple collaborative todo list. Watch two browser tabs edit the same data. Disconnect one, make changes on both, reconnect, and watch them merge without conflicts. That moment when it just works is when local-first clicks.
The cloud is not going away. But the assumption that every app needs to be cloud-first? That is already changing. And for the developers building the next generation of tools, that shift opens up possibilities that the always-online era never could.
