Local-first software

Local-first software is an approach to application design in which the user’s local device is the primary, authoritative store for their data, and the cloud is reduced to a synchronization and backup mechanism rather than the source of truth. It inverts the cloud-first assumption that has dominated web application architecture since the rise of client-server architecture and software as a service, in which the server holds the canonical copy and the client is little more than a view onto it.

The term was coined by the Ink & Switch research lab in the 2019 essay Local-first software: You own your data, in spite of the cloud, which set out the ideals that local-first software aspires to.

  • No spinners. Reads and writes hit the local store, so interactions are instant and the application keeps working with no network at all.
  • Multi-device. A user’s data is replicated across all their devices and reconciled through background synchronization.
  • Collaboration. Several users can work on shared data and converge without a central coordinator.
  • Ownership and longevity. The user holds their data and can keep using it even if the vendor disappears — data outlives the application that produced it.
  • Privacy. Because data lives on the device, the server need not see plaintext content to be useful. See privacy.

The defining technical move is to treat each device as an independent replica and to keep those replicas consistent through eventual convergence rather than through synchronous coordination. This is precisely the territory of eventual consistency: replicas are allowed to diverge while disconnected and are reconciled once connectivity returns.

The synchronization problem

The hard part of local-first is synchronization: reconciling the independent edits that several devices — or several users — make to overlapping data while they are disconnected. When two replicas have each edited the same item, the system has to decide which version wins, or merge them, without a central authority to arbitrate.

The common reconciliation strategies are drawn from distributed-systems research and applied at the application edge.

  • Conflict-free replicated data types (CRDTs) are data structures whose merge operation is deterministic and commutative, so any two replicas that have seen the same set of operations converge to the same state regardless of the order in which they arrived.
  • Operational transformation rewrites concurrent operations against each other so that the same edits applied in different orders produce the same result; it is the technique behind real-time collaborative text editors such as Google Docs.
  • Last-writer-wins takes the edit with the most recent timestamp as authoritative. It is simple to implement but silently discards the losing edit, so it suits data where the latest update is almost always the intended one.
  • Three-way merging keeps a shared base version and attempts to auto-merge concurrent changes, falling back to user intervention when the changes touch the same region, in the manner of a version-control merge.
  • Event sourcing resolves conflicts by replaying the ordered event log and deriving the merged state from it, trading implementation complexity for a full audit trail.

Local-first engines rarely commit to a single strategy. Many mix CRDTs for simple fields with three-way merging for rich documents.

Why it matters

The payoff is twofold. First, performance: because reads and writes are local, the application has near-zero latency and no round-trip dependency on the network, so there are no loading spinners and no degraded experience on a slow connection. Second, resilience: a local-first client keeps full functionality through network outages, partial connectivity, and travel, because the copy it depends on never leaves the device.

These properties have driven renewed interest as user expectations for responsiveness rise and as the supporting tools mature. Local stores such as SQLite — often compiled to WebAssembly for in-browser use — replication libraries, and hosted sync back-ends have together lowered the cost of building local-first applications.

Trade-offs

Local-first is not free. Synchronization machinery adds real complexity, and convergence bugs are subtle because they surface only when devices reconnect after long disconnection. Data that must not diverge — balances, inventory, anything subject to ACID principles — is poorly suited to a model that embraces divergence and reconciliation, and is better served by a server-authoritative design with strong consistency. Multi-device sync also raises the cost of encryption, access control, and backup, since the convenience of replication has to be weighed against the surface area of copies spread across devices.

See also

References