Local-first describes a set of software design principles, but implementations vary. The original Ink & Switch essay discusses offline work, collaboration, ownership, and long-term access to data. Evaluate each property when selecting an app.
Here's a clear definition: local-first software stores your data on your device first, and syncs to other places second. The app works fully offline. The data is yours whether or not the company behind the app exists next year.
That sounds subtle, but it changes the entire relationship between you and the software. In a cloud-first app, the server is the source of truth and your device is mostly a temporary window into it. In a local-first app, your device has the real data. The cloud, if it exists, is a helper.
The problem local-first solves
Most apps today are cloud-first by default. Your data lives on someone else's server. The app is essentially a UI for their API. When the service is down, or the company shuts down, or they change their pricing, you're stuck.
You've seen this happen. Evernote. Quip. Readmill. Dozens of others. The cloud giveth and the cloud taketh away.
Cloud-first tools are convenient because they make sync and collaboration easy. But they also create quiet dependencies:
- you need an internet connection
- you need the company to stay alive
- you need your account to remain in good standing
- you need pricing and export policies not to change
- you need the service to keep caring about your use case
For casual data, that may be fine. For notes, writing, code, research, personal archives, design files, finances, and long-term work, it becomes a risk.
What genuine local-first looks like
A truly local-first app has:
- Full offline functionality — not "read-only offline mode," but everything
- Files you can open elsewhere — your data isn't locked in a proprietary format
- Sync as a feature, not a requirement — the app works without it
You can add a few more tests:
- Fast local interactions — opening, editing, and searching should not wait on a network request
- Graceful conflict handling — if two devices edit offline, the app should help merge changes
- Recoverable data — backups and exports should be obvious, not hidden in a support article
The core question is simple: if the company's servers vanished tomorrow, what would you still have?
Apps that actually qualify
Obsidian — your vault is a folder of markdown files. Works offline. Sync is optional and pluggable. The files exist regardless of Obsidian's future.
Logseq — same model. Graph-based, but everything is plain text underneath.
Heynote — a scratch pad that lives on your machine. No account, no sync, no cloud.
Zed — code editor. Local by definition, with optional collaboration built on CRDTs.
Local-first also shows up outside note apps. Git is local-first in spirit: every clone contains the project history, and remote servers are synchronization points. Many photo managers, password managers, writing apps, and developer tools use similar ideas even if they do not use the phrase.
What local-first is not
Local-first does not mean anti-cloud. Sync is useful. Backups are useful. Collaboration is useful. The difference is the direction of dependency.
In a cloud-first system, the device depends on the server. In a local-first system, the server helps the device.
It also does not mean every file must be human-readable plain text. That is ideal for notes and documents, but some apps need structured databases or binary formats. The important part is whether the data is local, durable, exportable, and usable without asking permission from a remote service.
The CRDT connection
The reason more apps are going local-first now is CRDTs — Conflict-free Replicated Data Types. They make it possible to sync data between devices without a central server arbitrating conflicts. The technical barrier that made cloud-first the easy choice is slowly disappearing.
CRDTs are not the only way to build local-first software, but they matter because they make multiplayer local-first apps more realistic. Two people can edit, go offline, reconnect, and merge changes without one central database deciding every operation in real time.
That is why the idea is spreading from developer circles into mainstream productivity software. Users want instant local speed and reliable sync. Developers want apps that do not fall apart the moment a request fails.
Why it matters for privacy
Local-first does not automatically mean private. A badly designed app can still upload your data. But local-first makes privacy easier because the app does not need to send every interaction to a server just to function.
Less server dependency can mean less tracking, fewer data breaches, and fewer incentives to mine user behavior. It also gives users more practical control: local backups, local encryption, and local deletion become possible in a way cloud dashboards rarely match.
The buying checklist
Before trusting an app with long-term data, ask:
- Can I use it offline for real work?
- Where is the primary copy of my data?
- Can I export everything in a usable format?
- Can I back it up myself?
- What happens if I stop paying?
- What happens if the company shuts down?
If the answer is vague, the app is probably cloud-first with offline features. That can still be useful, but it is not the same thing.
Local-first isn't a compromise. For many categories of software, it is the better architecture. It just took the tooling a while to catch up.