Local-first architectures and CRDTs: instant applications, even offline

In most web applications every user action follows the same path: the browser sends a request, the server processes it, the browser waits for the response and updates the interface. It works as long as the network is fast and the server responds. When either of them slows down, the user stares at a spinner. When the network is missing altogether, as in a warehouse, on a building site or in a van, the application stops.

The local-first approach reverses the path: data lives first and foremost on the user's device, and the server becomes the synchronisation point.

How it works

The client keeps a copy of the data in a local database in the browser, such as IndexedDB or SQLite compiled to WebAssembly with storage on OPFS. Every read and write happens there, so the interface updates immediately. In the background, a sync engine exchanges changes with the server and with other devices as soon as the connection allows.

For the user, the result is an application that responds about as fast as a desktop program and keeps working when the network goes down.

The conflict problem and CRDTs

If two people edit the same data while offline, what happens when they reconnect? It is the central question of every local-first system.

CRDTs (Conflict-free Replicated Data Types) are data structures designed to answer it mathematically: they define merge rules such that, whatever order the changes arrive in, all copies converge to the same state. No locks on the central database are needed, and the server does not have to arbitrate every operation. Mature libraries such as Yjs and Automerge implement these algorithms for text, lists, maps and structured documents.

The concrete benefits

• Instant interface. Local operations take a few milliseconds, because they depend neither on the network nor on server load.
• Offline work. A dropped line or a backend problem does not block the operator: they keep working and changes are synchronised later.
• Real-time collaboration. Several people can work on the same document or list, seeing each other's changes as soon as they arrive.
• Less load on the server. Many reads no longer reach the backend.

The limits, to know before choosing

Local-first is not the right answer for every application, and CRDTs do not solve everything.

Convergence does not mean correctness

A CRDT guarantees that all copies reach the same state, not that this state respects business rules. If two offline operators sell the last item in stock, on synchronisation the data will converge without errors, but the stock level will be negative. Constraints of this kind, such as availability, balances and bookings, still have to be checked by a central authority, or handled with explicit reconciliation logic.

Permissions and security

If data is on the client, you need to decide carefully which data to synchronise to each user and validate every incoming change on the server. The client cannot be considered trustworthy.

Schema evolution

Updating the data structure is more complex when there are copies scattered across devices that might stay offline for days with an old version of the application.

Storage and initial sync

CRDTs keep metadata about the history of changes, which grows over time. The first data load on a new device also needs careful design, and browsers impose storage limits.

When it makes sense

Local-first gives its best in applications that are used intensively and often in uncertain network conditions:

• operational field tools: logistics, maintenance, surveys, inventories;
• editors and collaborative tools: documents, notes, whiteboards, planning;
• internal business applications where interface speed affects day-to-day productivity.

It is less suited to systems where almost every operation must be validated centrally in real time, such as payments or bookings with limited availability. Often the best solution is hybrid: local-first for most of the data, server confirmation for critical operations.

How we work

When we evaluate a local-first architecture we start from three questions: how often users work without a network, which data must be shared in real time, and which business rules must never be broken. The answers decide what lives on the client, what stays under the server's control and which synchronisation tool to use.

See also: our project archive.

Designing an application that also needs to work offline? Tell us about the project.