Open a note you wrote in a cloud app five years ago. Most of the time it opens — and that "most of the time" is exactly the problem. The document you typed, the words that are unambiguously yours, depend on a company still existing, a subscription still paid, an account still un-suspended, and a server somewhere still answering. Strip those away and the file is gone, even though nothing about the text itself required any of them.
Local-first software is the name a group of researchers and practitioners gave to a different default. The idea is small and stubborn: your data lives, in full, on your own devices. The application works whether or not there is a network. Sync, collaboration, and backup are real features — but they are added on top of a thing that already works alone, rather than being the only reason it works at all.
I
The cloud quietly became the original
The shift was gradual enough that few people chose it deliberately. A desktop word processor saved files you could see in a folder. Its web successor saves them to a database you will never touch, in a format you cannot read, behind credentials that can be revoked. The copy on your screen is a temporary, downloaded reflection; the real document is the row on a server you do not control.
This is convenient, and the convenience is not a trick. Collaboration in a shared document genuinely is easier than emailing versions back and forth. The cost is hidden in the verb: you no longer have the file, you access it. And access, unlike possession, can be taken away by a price change, an outage, a policy update, or a quiet shutdown of a product that wasn't profitable enough.
What "local-first" actually means
A working definition, paraphrased from the original 2019 essay by Ink & Switch: the primary copy of your data is on your local device, the software is fully usable offline, and any syncing to other devices or people is layered on without making the network a hard dependency.
You should not need permission, or a signal, to open your own notes.— the local-first premise, in one sentence
II
Ownership, speed, and the long now
Three benefits tend to fall out of the local-first stance, and they reinforce one another. The first is ownership in a plain sense: if the bytes are on your disk in a format you can export, no remote decision can separate you from your work. The second is speed. An app that reads and writes to local storage answers in the time it takes a disk to respond, not the time it takes a request to cross the planet and come back. Typing never waits for a round trip.
The third benefit is the one that takes years to appreciate: longevity. Files in an open or inspectable format on hardware you own can outlive the company that made the software. Plenty of people still open documents from defunct programs because the bytes were sitting on a drive, legible, waiting. That is a kind of permanence the rented document can never offer.
Sync should be a feature you can lose without losing the work.— on treating the network as an enhancement
III
It was easy to want, and hard to build
For a long time the honest objection to local-first was technical, not philosophical. The hard part is collaboration without a central referee. If two people edit the same paragraph on two devices that were briefly offline, something has to merge those edits sensibly when the connection returns — without a server quietly declaring one version the winner and discarding the other.
The answer that made local-first practical is a family of data structures called CRDTs — conflict-free replicated data types — which let independent copies of a document change on their own and then converge to the same result, no central authority required. Paired with cheaper local storage and better sync libraries, they turned a nice principle into something you can actually ship. The constraint that justified the cloud has loosened.
IV
A direction, not a doctrine
Local-first is not a demand that everything run offline forever, nor a rejection of collaboration, nor nostalgia for files in folders. It is a reordering of priorities: make the thing work for one person on one device first, treat the network as something that makes it better rather than something that makes it exist at all. Most software today is built the other way around, and you feel it every time a spinner stands between you and a sentence you already wrote.
The pitch is modest, which is why it tends to stick. Keep your data close. Let the software keep working when the wifi doesn't. Make sure that in ten years you can still open the thing you made today — without asking anyone's permission to do it.