Local-First Software
Software whose data lives on the user's devices first — the network helps but does not rule — and which keeps working when the cloud is slow, missing, hostile, or gone.
There is a particular moment that has happened to most users of cloud software, even if they have never named it. The connection is poor, or the service is briefly down, or the vendor has quietly changed the plan, and a thing you thought of as yours stops behaving like it is yours. The document was always somewhere else. You only had a window onto it.
Cloud software gave us collaboration, and the convenience was real; but it also, quietly, changed the ownership model. The server became the real computer, and our devices became terminals with better screens. Local-first software is the attempt to keep the parts of the cloud that are genuinely useful — sync, multi-device workflows, real-time collaboration, off-site backup — without letting the cloud become the authority over a person’s own work.
The canonical reference for this argument is Ink & Switch’s Local-first Software research area, especially the essay Local-first software: You own your data, in spite of the cloud. What follows is largely downstream of that work.
The inversion
A local-first application treats the user’s device as a real place where the work lives, not as a cache for a remote database. The network is still valuable — but its job is to move state between devices and people, not to decide whether the work exists at all. It should not be required for every keystroke, every lookup, every save, or every act of permission.
That is a small-sounding sentence with large architectural consequences. Where the cloud-first system treats the server as canonical and local state as a temporary projection, a local-first system reverses the polarity: local state is the canonical record, and servers are optional infrastructure for sync, backup, and collaboration. The shift propagates into performance, failure modes, privacy, product longevity, data formats, identity, access control, and the user’s ability to bend her own tools.
Why it matters
The reasons I keep returning to this area cluster into a few threads, all of them tied to the broader question of Personal Computing — whether the machine in front of a person is a place she can live in, or a kiosk she negotiates with.
The most obvious thread is durability. Personal artefacts should not depend on a company continuing to run a server, preserve a pricing plan, maintain an API, or allow an account to exist; a note, drawing, dataset, program, or document should be able to outlive the service used to create it.See also the Post-Collapse Computing essays, which take the concern further than I usually do. Plain, durable export formats are the unglamorous condition of this — you own your data is only real if you can leave.
There is a related but distinct argument from performance as felt by the user. Local interaction should feel local. Typing, searching, opening, saving — the small acts that make up a working day — should not stage a network round trip every time, unless the problem genuinely demands it. The cloud taught a generation of developers to treat latency as someone else’s concern, and most software has been worse for it.
A third thread, harder to name well, is collaboration without surrender. Cloud collaboration was not a mistake; it made shared work easy in a way the desktop never quite managed. The mistake was letting that convenience require centralised ownership. The interesting question is how to make multi-user software that feels as smooth as a Google Doc while preserving the file, the local tool, the offline session, and the user’s claim on all of them.
Underneath these is a structural concern about modularity. A system is healthier when its parts can be replaced — sync through one provider today, self-host tomorrow, export next year, script against the data whenever. Local-first is not only about where bytes live. It is about whether the architecture permits divorce.
The architectural tension
Old desktop apps gave users speed and ownership but were generally bad at collaboration. Cloud apps fixed collaboration by moving authority away from the user. The local-first project is the attempt to keep both:
local agency with cloud-level collaboration
This is harder than it sounds, because it asks sync to be a first-class problem rather than a patch, and it asks product design to face the distributed-systems reality that most software hides until it is unrecoverable. Users should not need to know the theory. But the system should respect the theory: devices go offline, clocks disagree, people edit concurrently, keys get lost, servers disappear. An application that pretends otherwise is borrowing trouble it will eventually have to repay.
Open questions
We already know how to write files to disk. The hard part is making software that is local, collaborative, secure, comprehensible, and pleasant at the same time, and the open questions tend to live in the ands.
The first is the programming model. What should the API look like for applications whose state is replicated across devices and users — and how much of that replication can be expressed with CRDTs, operational transforms, event logs, or version-control-like histories without forcing every developer to become a distributed-systems researcher?
The second is permissions and identity. What are the right primitives for access control when there may be no central server to ask, and can end-to-end encrypted collaboration be made comprehensible to users who do not think in keys?
A third concerns durability of formats. Efficient binary representations are in tension with the long-term legibility a personal archive needs; the question is not which to pick but how to make the application format and the archive format coexist gracefully.
A fourth is the surface of history itself. Local-first software has the option to expose conflicts, provenance, and undo in ways cloud software usually hides. How much of this is useful to ordinary users, and what does it look like when it is?
And there is a more diffuse one I do not yet know how to phrase well: whether local-first principles, in addition to making software more private and more durable, also make it more educational and hackable, in the spirit of Malleable Software — whether owning your data turns out to be the precondition for being able to do anything interesting with it.
Promising directions
The directions I find most credible are the ones that have moved from research demo to working building block. CRDT libraries — Automerge, Yjs, and a few smaller ones — have made replicated rich text and structured documents practical, if not yet effortless. Local-first databases give application developers a usable API without dragging them into replication theory. Capability-based sharing, where access is delegated by handing someone a token rather than consulting a permission server, is starting to look like the right primitive for collaboration that respects the Personal Computing stance. End-to-end encrypted sync, with the server demoted from authority to relay, is becoming feasible at consumer scale. And there is a quieter strand of work on user-visible history — closer to Git in structure, but designed for documents and for people who are not programmers — which is one of the more interesting open UX problems in the area.
Underneath all of these, peer-to-peer and local-network sync deserves more attention than it gets, not as ideology but as resilience: nearby devices should not need a datacenter to exchange a document.
A working stance
I am most interested in local-first software when it increases user agency without turning the user into a sysadmin. The point is not to make everyone think about replicas, merge semantics, backup policies, or key rotation all day; the point is to build systems whose defaults are humane and whose internals remain available when the user wants to look. Good software should feel fast, important software should outlive its vendor, personal software should remain inspectable, and collaborative software should not require giving up ownership in order to function. Local-first is one of the few research areas that treats these as one problem rather than four.