Local-First Software: What "Owning Your Data" Actually Means

"Own your data" gets used as a slogan constantly, often without much technical substance behind it beyond "don't use the cloud version." The actual, specific technical vision behind that phrase has a real origin point: a 2019 research essay from the software lab Ink & Switch, written by Martin Kleppmann and collaborators, that laid out exactly what a piece of software would need to do to give users genuine data ownership without sacrificing the real-time, multi-device collaboration that made cloud software appealing to begin with. It's not a vague philosophy — it's seven specific, checkable technical properties, and the math that makes the hardest of them actually achievable predates the essay by nearly a decade.

The Seven Ideals, Specifically

The essay, titled "Local-First Software: You Own Your Data, in Spite of the Cloud," lays out seven properties a genuinely local-first application should have, and the specificity is the point — this isn't a mission statement, it's closer to a checklist. No spinners: because your data lives on your own device, the app should never need to wait on a network round-trip just to show you something you already have. Multi-device: your data should sync across every device you use, the way cloud software already does. Offline: full read and write functionality with no internet connection at all, not a degraded read-only mode. Collaboration: real-time multi-user editing, matching what tools like Google Docs already do well. Longevity: your data should remain usable for decades, independent of whether the original company or its servers still exist. Privacy: your data should be encrypted such that the service provider itself can't read it, not just protected from outside attackers. User control: genuine ownership, including the ability to copy, modify, or delete your own data without needing permission from anyone else.

Read individually, most of these aren't new or controversial — plenty of older desktop software satisfied several of them by simply not having networked collaboration at all. What makes the local-first proposal genuinely difficult is the combination: collaboration and offline together are in direct tension, because real-time multi-user editing has traditionally required a central server to arbitrate conflicts when two people edit the same thing at the same time — exactly the kind of centralized dependency the other six ideals are trying to escape.

The Math That Actually Resolves That Tension

The specific technical tool the essay identifies as the way out of that bind is a data structure category called CRDTs — Conflict-free Replicated Data Types — a concept formally established in research by the computer scientist Marc Shapiro and collaborators around 2011, predating the local-first essay by roughly eight years. A CRDT is built around a genuinely different assumption than a traditional database: instead of requiring a single authoritative server to decide the correct order of conflicting edits, a CRDT is mathematically designed so that edits made independently, on different devices, completely offline from each other, can later be merged back together automatically and always produce the same, correct final result — no central arbiter required, and no possibility of an unresolvable conflict, by mathematical construction rather than by careful engineering effort.

Practically, this works through one of two general approaches: state-based CRDTs, where each device holds a full local copy of the data and periodically exchanges and merges complete state with other devices using a merge function specifically designed to be safe regardless of order or timing, and operation-based CRDTs, where devices instead exchange a record of the specific changes made, which get replayed and applied elsewhere. Either way, the property that actually matters for local-first software is the same: two people can edit the same document while both completely offline, on airplanes on opposite sides of the planet, and when they eventually reconnect, their edits merge back together correctly and automatically, without either person's changes being silently discarded or requiring a human to manually resolve a conflict. One of the direct outputs of the original Ink & Switch research is Automerge, an open-source JavaScript CRDT library that brings this exact merge behavior to ordinary JSON data, now used as a building block by other local-first tools built after it.

What This Actually Looks Like in a Real, Shipping App

The clearest mainstream example of local-first principles actually shipping in a widely used product is Obsidian, a note-taking application whose core design decision is that your notes are stored as plain, readable Markdown files directly on your own device rather than locked inside a proprietary cloud database you can only access through the app itself. That single choice satisfies several of the seven ideals simultaneously and almost automatically: longevity, since a folder of plain text files will still be readable decades from now with or without Obsidian's continued existence; user control, since you can open, copy, or edit those files with literally any text editor on the planet; and offline, since there's no server round-trip involved in reading or writing a file already sitting on your own disk. The broader ecosystem has grown considerably since the original 2019 essay — newer tools including Triplit, Evolu, Zero, and LiveStore have emerged specifically to give developers building new local-first apps a CRDT-backed sync layer to build on rather than requiring every team to implement this genuinely difficult conflict-resolution math themselves, and a dedicated Local-First Conf now runs annually, evidence this has moved from a single influential essay to an actual, if still comparatively small, corner of the software industry building real products around its specific technical claims.