Local-first software: why your data should live on your device
Cerebrix — Development Collective
The cloud made software convenient, but it also made it fragile, slow, and dependent on trust. Local-first is the quiet counter-movement — here's how it works, where it shines, and how to start.
For a decade the cloud won every argument: your data in someone else's datacenter, accessible from any device. But the trade-offs are showing — offline is a hard failure, sync is slow, and "we store your data" is a trust promise users can't verify. Local-first is the counter-movement, and it's where our own products live.
What local-first means
The software runs and stores data on your device first. The cloud becomes an optional sync layer instead of a requirement. Your files, codes, and settings work whether you're online, offline, or on a plane.
Why we build this way
- Reliability — no server, no outage. The feature works because it never depends on a network call.
- Privacy by architecture — data that never leaves your device can't be leaked, sold, or subpoenaed.
- Speed — reading from local storage beats any network round trip.
- Ownership — you keep your data even if a company disappears.
How sync actually works
The hard part of local-first is merging changes made on different devices. The engineering answer that made the movement possible is CRDTs — conflict-free replicated data types.
The idea, simplified: every change carries metadata (who made it and when), and merges are defined so that any two devices converge to the same result — no "last write wins" surprises, no lost edits.
You don't need CRDTs to start, though. Many apps only need one of these simpler patterns:
- Single-writer — one device edits at a time; sync is just copying
- File-based — each piece of data is a file; conflicts are rare and visible
- Append-only — logs and inboxes only grow; merge is trivial
We picked patterns like these for QRForge (no sync at all) and ShieldMail (a disposable, append-only inbox) before we ever needed CRDTs.
Where local-first shines today
- Notes and documents — read and write anywhere, sync when you're back online
- Developer tools — CLIs and editors already work this way; you just never called it local-first
- Personal data vaults — passwords, keys, and health data that should never be a cloud liability
- Privacy products — the whole point is that the server doesn't have your data
The honest trade-offs
Local-first isn't free. Syncing across devices is genuinely hard engineering, and multi-user collaboration is the hardest part of all. That's why we scope it carefully: QRForge needs no sync at all, and ShieldMail's inbox is disposable by design.
Cloud-first asks you to trust a company with your data. Local-first makes the trust unnecessary.
How to start
You don't need to re-architect anything. Start with one rule: default to storing data on the device, and treat the server as a sync target, not a source of truth. Pick the simplest sync pattern that fits, and only reach for CRDTs when merging edits across devices becomes a real requirement.
We think the trade is worth it. Your data is yours — the software should work like that's true.
Have a project in mind?
We build web apps, mobile apps, and browser extensions. Let's talk about yours.