The Local-First Software Trend

Notion Didn't Open on the Plane

Last year, flying to Jeju Island (a popular domestic destination in South Korea — think Korea's Hawaii), I opened Notion. Offline mode was on, but the cache must have expired because I got a blank page. My travel checklist was in there. Spent an hour staring at nothing. That's when it hit me: isn't it weird that my data isn't on my device?

That's when I started paying attention to Local-first software.

What Local-First Actually Means

Local-first means the owner of the data is the user's device, not the server. The cloud is just a sync mechanism — the complete dataset always lives locally. Everything works without internet; when you reconnect, it syncs automatically.

The concept isn't new. Git is exactly this. Full history lives locally, sync via push/pull. But the movement to apply this to regular applications is growing.

CRDT: The Magic-Sounding Technology

The core tech behind Local-first is CRDT (Conflict-free Replicated Data Type). Two people edit the same document offline simultaneously, and when they reconnect, changes merge automatically without conflicts. Imagine Git without merge conflicts.

Reality is messier, of course. CRDTs often use simple strategies like "last write wins," which can produce unintended results with complex data structures. List ordering, for example.

Libraries like Automerge and Yjs are tackling this. But from personal experience, the learning curve is steep. I spent an entire weekend wiring Yjs into a side project and didn't get it working until day three. (2:14 AM on day three, to be precise.)

Local-First Tools You're Probably Already Using

Obsidian is the poster child. Markdown files stored locally, sync via their paid service or iCloud — user's choice. Works perfectly offline.

Linear adopted Local-first architecture too. Data cached in IndexedDB makes the app insanely fast. Click something and it responds instantly. Almost no loading spinners waiting for server responses.

Figma uses some Local-first elements too. Real-time collaboration is CRDT-based, so multiple people can edit simultaneously without conflicts.

Why It's Hard for Developers

First, state management gets complex. The server isn't the single source of truth anymore, so "which device has the latest data?" is an ever-present question.

Second, security. If data lives locally, encryption must happen on the client. More complex than server-side encryption.

Third, initial load. Keeping the full dataset locally means a full sync on first use. Large datasets make this painful.

I hit all three on my side project. State management alone produced 7 bugs, and debugging was twice as hard as server apps. "When was this data created?" — impossible to trace.

The Direction Is Right, Though

The more cloud-dependent we become, the bigger the risk. Service shuts down? Price hikes? Server outage? Having data on your device reduces all of these.

The tooling is still immature and complex for mainstream adoption. But Obsidian's success and Linear's snappy UX prove users want this direction.

My next side project will be Local-first. With the Yjs experience under my belt, it should go faster this time. Probably.