The Local-First Software Renaissance: Why Your Apps Are Coming Back to Your Device

In 2019, a research lab called Ink & Switch published an essay outlining what it called "local-first software." The premise was simple and the implications were significant: applications should store their data on the user's device, work fully without an internet connection, and treat the cloud as a sync layer rather than the source of truth. The response from the developer community was warm, intellectually engaged, and mostly theoretical. The tooling to build local-first apps at production quality did not really exist yet.

Seven years later, it exists. ElectricSQL hit version 1.0 in March 2025, bringing production-stable Postgres sync to local SQLite. Automerge and Yjs — the two dominant CRDT libraries — have matured significantly. The Local-First Conference in Berlin drew researchers, startups, and engineers from established companies. And on-device AI has given the architectural approach a new commercial reason to exist that goes beyond ideology.

What local-first actually means

The term gets used loosely, so it is worth being precise. A local-first application stores its primary data on the user's device — in a local database, as plain files, or in browser storage — and syncs that data to other devices or a server as a secondary operation. The critical design invariant is that the app works fully without a network connection. Not "it shows cached data" — it works, reads and writes, with the full feature set.

Ink & Switch's original seven principles include: instant operations with no loading spinners, full offline functionality, seamless sync across devices, real-time collaboration, data longevity (the app works even if the company shuts down), security by default, and user data ownership with export portability. Most cloud-first apps fail at least four of these. Most local-first apps built on current tooling can hit all seven.

The technology that makes it possible: CRDTs

The reason local-first sync was previously impractical is merge conflicts. If you edit a document on your phone while offline, and someone else edits the same document on their laptop, how do you merge the two versions when your phone reconnects? The naive approach is to pick one version and discard the other, which is catastrophic for collaboration. The sophisticated approach involves operational transforms — complex algorithms that work, but require a central server to arbitrate.

CRDTs, or Conflict-Free Replicated Data Types, solve this problem with mathematics rather than infrastructure. A CRDT is a data structure designed so that concurrent edits on multiple replicas can always be merged into a consistent result without any central coordinator. The math guarantees eventual consistency — all replicas end up with the same state — without ever needing a server to adjudicate. Google Docs, Figma, and WhatsApp all use CRDTs for their collaborative and cross-device sync features.

For local-first apps, this means two phones can both edit the same document while entirely offline, reconnect, and arrive at a correct merged result automatically. The merge conflict nightmare that developers feared turns out, in practice, to be largely non-existent for typical document and data editing scenarios.

The tools are production-ready

Yjs is the industry default for real-time collaborative text editing. Written in JavaScript with a fast Rust port (Yrs), it integrates directly with ProseMirror, Tiptap, and CodeMirror — covering most of the rich text editor landscape. If you have used a web-based document editor in the last three years, you have probably used Yjs without knowing it.

Automerge takes a different approach, storing the complete history of every change as a first-class object. This makes it more like Git for app data: you can branch, diff, merge, and cherry-pick changes across replicas. Compiled to WebAssembly for web use, it trades a larger footprint for richer history capabilities.

ElectricSQL occupies a different niche: instead of managing CRDTs directly, it syncs subsets of a PostgreSQL database to local SQLite on the client. For teams already running Postgres, this is the lowest-friction path to local-first architecture — your existing database stays; you add a sync layer in front of it. Version 1.1, released in August 2025, delivered 102x faster writes and 73x faster reads compared to the previous version. It is in production at Trigger.dev and handling millions of daily updates.

Why the timing is right in 2026

Three converging forces are driving renewed interest in local-first architecture beyond developer idealism.

First: on-device AI. Neural processing units delivering 70+ TOPS are now standard in flagship phones. Apple's Foundation Models run a 3-billion-parameter language model entirely on-device on iPhone and Mac. When AI inference moves to the device, the data it operates on naturally follows — you cannot have a truly private AI assistant if all your notes and documents live on a vendor's servers. Local-first data architecture and local AI inference are a natural pair.

Second: cloud fatigue and privacy regulation. Years of data breaches, opaque AI training policies, and service shutdowns have raised the cost of cloud dependency in users' minds. GDPR, HIPAA, and CCPA compliance is dramatically simpler when user data stays on user devices. Healthcare, legal, and financial-services teams are increasingly drawn to local-first tools precisely because they simplify the compliance calculus.

Third: performance. Linear's project management tool — one of the most cited examples of local-first architecture — stores its primary data in IndexedDB in the browser and syncs in the background. Every action is a local write first. The result is a UI that feels instantaneous compared to cloud-first tools that must round-trip to a server on every click. Teams consistently describe it as the fastest project management tool they have used. Speed, not philosophy, is what gets users to switch.

The business model problem, and how it is being solved

The obvious objection to local-first software from a business perspective: if users own their data and can export it freely, what do you charge for? Obsidian, the most successful local-first app by user count (over one million active users), has answered this cleanly. The app is free and open-source. Notes are stored as plain Markdown files you own entirely. Obsidian Sync — an optional add-on at $4 per month — provides encrypted sync across devices. You are paying for the service, not the data lock-in. The business model works because the product is excellent, not because users are trapped.

ElectricSQL and PowerSync have landed on the open-core model: self-host the sync engine for free, pay for the managed cloud version. Linear charges subscription fees for team features and integrations, not for data custody. The pattern is emerging: local-first companies charge for convenience, reliability, and collaboration features — not for holding your data hostage.

The ecosystem is still early by the measure of mainstream developer familiarity. Building a production local-first app requires understanding CRDTs, sync semantics, and conflict resolution at a level most application developers have not needed before. The tooling continues to improve, but there is a reason the Ink & Switch essay compared the state of local-first development in 2025 to React in 2013. The technology is ready. The documentation and developer experience are catching up.