Local-first software: what it means and how to tell if a tool actually is

"Local-first" started as a specific engineering idea — a 2019 essay from Ink & Switch about software where the primary copy of your data is on your own device and the cloud is an enhancement. It has since become a label applied to cloud apps that added an offline cache.

The distinction is worth being able to check, because it determines what happens to your work when the network, the subscription or the company goes away.

The three tests

1. Work offline for an hour. Not a minute. Disconnect and use the app for real: create things, edit things, search, navigate to something you have not opened recently.

A genuinely local-first app behaves identically. A cloud app with a cache typically lets you edit what is already open and then fails at the first thing it has not cached — search across everything, an older document, a file attachment.

2. Find your data on disk. Where does it live, and what is it?

• Plain files in a folder you chose — Markdown, SQLite, standard media. The strongest form: another program can read them today.
• A single opaque database in an application support directory. Acceptable if it is a documented format such as SQLite, and if export exists.
• Nothing on disk except a cache. Not local-first, whatever the marketing says.

3. Ask what happens if the company shuts down tomorrow. Answers that hold: the app keeps working on data already on your machine; the format is documented or open; there is an offline licence rather than a subscription check.

Answers that do not hold: "we would give notice and let you export." That is a promise from an organisation that, in the scenario being discussed, no longer exists.

What you give up

Local-first is not free, and the trade-offs are real:

• Collaboration is harder. Merging concurrent edits without a server is a genuinely difficult problem. Tools solve it with CRDTs, and the results are good but not always as immediate as a server-authoritative app.
• Sync is your problem more often. Conflicts surface to you rather than being resolved centrally.
• Storage is on your device, so a large archive is your disk usage and your backup responsibility.
• Cross-device is less seamless. Often good, occasionally fiddly, rarely as invisible as a pure cloud product.

Whether those matter depends on the work. For a shared operational tool a team depends on, server-authoritative is often the right choice. For notes, writing, personal archives and anything you expect to still want in ten years, local-first is the safer default.

A useful middle ground

Several tools are not local-first but behave well anyway: they keep data in an open format, sync through storage you control, and export completely. That combination gets you most of the durability without requiring the architecture.

The property you actually want is not being locked in. Local-first is one way to get it. Open formats plus real export is another, and it is available from far more products.

Ask what remains if the vendor stops existing. If the answer is "my files, in a format something else can open", the label on the box does not matter.

Checking the claim quickly

1. Turn off the network and use the app properly for an hour.
2. Search your filesystem for the data. Open the largest file and see what it is.
3. Read the pricing page for the words "offline", "perpetual" or "licence" versus "subscription required".
4. Look for a documented file format or an open-source client.

Two of four is a reasonable product with good portability. Four of four is genuinely local-first. Zero of four with the phrase on the homepage tells you something about the company, and it is worth noticing before your work is inside.