Local-First
Software and data that lives on your own devices, works without an internet connection, and syncs peer-to-peer — without requiring someone else’s server to function.
The Idea
Most software we use today is built on an assumption: your data lives in a data center somewhere, and you access it via a network connection. When the connection is slow, you wait. When the service is discontinued, you lose your data. When the company changes its terms, you adapt. The convenience of not managing your own infrastructure comes at the cost of not controlling your own information.
Local-first inverts this. Your data lives on your device. The software runs without a network connection. When you sync with other devices or collaborators, that’s an optimization — a way of sharing what you already own — not a requirement for basic function.
The term was formalized by the Ink & Switch research lab in a 2019 paper (“Local-First Software: You Own Your Data, in Spite of the Cloud”) that described seven ideals, among them: no spinners on slow connections, your work is preserved if the service shuts down, you can use it on a plane, you can share with collaborators without going through a server, it works forever even after the company is gone. These aren’t exotic requirements. They describe what good software has always done, before the cloud model made dependency the default.
The Technical Basis
Local-first software became easier to build with the development of CRDTs — Conflict-free Replicated Data Types. CRDTs are data structures that can be modified independently on different devices and then merged without conflicts, without requiring a server to adjudicate. They make it possible to sync without coordination — which is what local-first requires.
This is hard technical work. The cloud model is easier to build against. Which is why most software doesn’t bother, and why local-first software is still uncommon despite being clearly superior for most users’ actual needs.
The Tension
Local-first software requires someone to maintain the local infrastructure. Someone has to reboot the servers, manage storage, handle upgrades. The cloud model offloads that maintenance — you don’t have to think about where the data center is or whether the disks need replacing.
This maintenance burden is not evenly distributed. Local-first is easier to sustain if you have technical knowledge, stable hardware, and time to manage it. People without those resources may be better served by cloud software, even with the dependency trade-offs. “Local-first” as a universal prescription would be appropriate-technology applied inappropriately.
The honest claim is narrower: for people who have the capability to maintain local infrastructure, local-first software produces meaningfully better outcomes over time. It’s worth building that capability. It shouldn’t be required.
Connections
- appropriate-technology — local-first as the technical expression of this principle
- conviviality — Illich’s test applied to software architecture
- selective-technology — choosing which dependencies to accept
- shadow-work — the maintenance work cloud services hide and local-first makes visible
- Stewart Brand — whole-earth catalog as ancestor: own your tools
- whole-earth-catalog — the same “access to tools” logic applied to software
Further Reading
- Kleppmann et al. “Local-First Software” (Ink & Switch, 2019)
- LoFi (lofi.so) — community resources