Local-First Software: What It Is and Why It Matters

Local-first software stores your data on the device you're in front of, not on a remote server. It syncs across your devices in the background and keeps working when you're offline, so your files stay with you even if the vendor pivots or the network drops.

Why the cloud stopped feeling safe

Every cloud tool asks you to trust a company that has its own incentives. In November 2023, Evernote capped free accounts at fifty notes and a single notebook, leaving longtime users to either pay up or export their archives. A decade earlier, Google shut down Google Reader in March 2013, giving loyal users until July to move their subscription lists to a different tool. These aren't unusual events, they're the normal lifecycle of cloud products, and they keep happening because the company owns the database while the user owns only a login.

Local-first software is the name for a different model, where the copy on your laptop or phone is the primary copy and the cloud is demoted to a sync relay. The idea isn't new, and plenty of apps have shipped with offline support over the years. What's new is the vocabulary. The 2019 essay Local-first software by Martin Kleppmann, Adam Wiggins, Peter van Hardenberg, and Mark McGranaghan, published by Ink & Switch, gave the space a shared definition and a shared target to aim at. Most of the framing below comes from that essay, and I'll link back to it when it's useful.

What local-first software means

"Local-first" is more specific than "offline-capable," and more specific than "your data is exportable to a file." The Ink & Switch essay proposes seven concrete ideals a local-first tool should aim for.

Here is a short gloss of the seven ideals.

1. No spinners. Work happens at the speed of your device, not at the speed of your network.
2. Your work isn't trapped on one device. You can keep using it across a laptop, phone, and tablet.
3. The network is optional. Offline is a normal state, not an error state.
4. Collaboration without conflict. Multiple people can edit the same document at the same time without the tool losing changes.
5. The long now. Your files keep working in ten years, even if the company that made the tool is gone.
6. Security and privacy by default. Your data isn't decrypted on a machine you don't control.
7. You retain ultimate ownership and control. The files are yours to copy, modify, and hand to another tool whenever you want.

Few tools hit all seven at once today, and the essay was open about that. Think of the list less as a pass or fail checklist and more as a direction of travel. A tool can be strongly local-first on the first three ideals and weaker on the fourth and sixth, and still meaningfully belong to this space.

How local-first apps work under the hood

Four pieces show up in almost every local-first design, and each one fights a different battle.

A primary copy on the device. The app reads and writes to a local database, not to an HTTP endpoint. Every action is a local transaction first. If the network never comes back, you still have every byte of your work.

Background sync. A sync layer watches the local database and ships changes to a server or a peer whenever a connection is available. The user interface never blocks on this step. If you've ever watched a Dropbox icon spin quietly in the corner of your screen after reconnecting your laptop, you already know the pattern.

Conflict resolution that doesn't lose work. When two devices edit the same document offline and then meet again, the tool has to decide how to combine the edits. Traditional systems pick a winner and drop everything else. Local-first tools lean on CRDTs, a family of data structures that combine concurrent edits into one consistent result by construction. CRDTs are the mechanical engine that makes the fourth ideal work without a central server.

Durable, portable storage. The local file is a binary log or snapshot the user can copy, back up, and move to a new machine. If the app is built well, the format is documented or open-sourced, so a future version of the tool, or a different tool, can still read it. That's what closes the loop on the fifth and seventh ideals.

None of these four pieces are free. Local-first software took a long time to become practical partly because all four had to mature together.

The trade-offs people don't talk about

Local-first has real downsides. Skipping over them would be dishonest, so here they are.

Onboarding is harder. No account server holds your files, so the first time you open the app, it has to decide where its local database lives and how it'll sync, and you have to understand enough of that to pick sensible defaults.

Long merges can look strange. CRDTs never lose data, so when two people edit the same paragraph offline for an hour each, you end up with both versions living side by side. That's mathematically correct and sometimes humanly confusing, and a lot of the ongoing research in this space is about making those moments nicer to read.

Sharing is awkward. Cloud tools handle sharing cleanly because the central server tracks who has access and pushes updates to every connected client as soon as the permissions change. Local-first apps have to build that experience on top of a peer-to-peer or relay model, and first-time sharing flows are often clunkier for the invited user.

Mobile is harder than desktop. Apple's background tasks cap background refresh windows at around thirty seconds and warn developers that the system may not schedule them at all under common conditions. Android imposes similar limits for battery reasons. Local-first design pushes against all of these, so tools that do this well usually invest more in their mobile clients than in their web app.

None of these downsides are fatal. They're the price you pay for data that doesn't vanish when a vendor changes its business model.

When local-first is the right call

Some workloads are a great fit. Personal knowledge work is the most common one, because the value of your notes compounds over years and the cost of losing them hurts. Creative tools where you iterate for hours offline benefit for the same reason, plus the latency win. Field work and travel are the classic offline cases, from survey apps to sketchbooks to reading apps. Small-team collaboration where everyone trusts each other but nobody wants a vendor lock-in also maps well onto this model.

Some workloads don't fit. If you need strict access control, per-row permissions, and a central audit log, a traditional server-centric system is the sharper tool. If your data only matters for a few hours, like a chat message or a one-off query, the long-term ownership story doesn't buy you much. Pick the model that matches how the data is used.

How CoCube fits in

CoCube is built local-first from the ground up. Every document lives as a Loro CRDT in an in-browser database on your device, and the server is a relay that ships binary CRDT deltas between devices you own. You can edit offline, close the tab, open it on another machine, and the state catches up without a merge dialog. The underlying format is documented, and the sync protocol is a thin layer over standard CRDT operations, so your document is portable by design.

The broader motivation lives in the post on composable software, which is why I started building CoCube in the first place. Local-first is the data story. Composable is the tool story. They reinforce each other, because if your data lives with you, it becomes reasonable to build tools around it that only you need.

What to read next

If you want to understand the data structures that make local-first technically possible, start with the CRDT article. If you want to understand why this model belongs at the center of a personal knowledge base, the PKM guide is the pillar article for that. If you've heard the term "second brain" and want to know how it fits into the local-first picture, the second brain article covers that. If you want to see how CoCube's reactive cell model connects to the spreadsheet you already know, the reactive programming post explains that bridge. For a practical comparison of tools that implement local-first principles, the Obsidian alternatives and Notion alternatives roundups are the place to start.

Local-first software doesn't make the cloud obsolete. It puts the cloud back in the role it was always supposed to play, a delivery mechanism for bytes that already belong to you.