Why Local First Software and CRDTs Are the Future of Apps

I have been thinking a lot about how most web apps work today. You open a browser, the app loads, and then everything you do goes through a server. Every click, every keystroke, every scroll might fire a request somewhere. If the internet hiccups, your app freezes or shows a spinner. That is just how things are.

Except it does not have to be.

Local first software is an architecture where the user’s device holds the primary copy of the data. The cloud exists as a backup and a sync layer, not the other way around. This is not a new idea. Desktop apps worked this way for decades. What is new is that web apps are finally catching up.

The problem with server first

When your data lives on a server, every interaction has a round trip. You save a note, it travels to a database, the response comes back, the UI updates. On a fast connection this feels fine. On a slow or flaky connection it feels broken. Mobile networks in Nepal can be unpredictable. I have seen users abandon apps because the latency made the experience feel sluggish.

Beyond latency, server first apps have a single point of failure. The server goes down, your app is useless. The company hosting the server shuts down, your data is gone. You are at the mercy of someone else’s infrastructure.

Enter CRDTs

The hard part of local first has always been conflict resolution. Two people edit the same document offline. They both come back online. Whose changes win? Traditional approaches use locks or last write wins, both of which suck.

CRDTs solve this mathematically. A Conflict-free Replicated Data Type guarantees that if every replica receives the same set of updates, they all converge to the same final state regardless of order. No locks. No conflict resolution UI. No data loss.

This is not theoretical. Automerge is a popular CRDT library that works in JavaScript. Yjs is another one used in production by several collaborative editing tools. Both have solid TypeScript support and can be dropped into a SvelteKit app.

What I find exciting

The local first movement is gaining momentum. Tools like Electric SQL let you sync Postgres data to local SQLite on the client. Zero is a sync layer built on top of these primitives. Replicache gives you a typed cache on the client with server side reconciliation.

What excites me most is the user experience implications. Local first apps feel instant because there is no network round trip for reads. Writes happen locally and sync in the background. Collaboration works offline. Privacy improves because less data leaves the device.

Practical considerations

Local first is not free. You need to handle schema migrations on the client. Storage limits on mobile devices are real. Sync logic adds complexity to your codebase. And some apps genuinely need a central authority for things like payments or moderation.

But for content creation tools, note taking apps, project management software, and anything where the user generates data, local first is worth considering seriously.

I have been experimenting with adding a local first layer to a side project using Yjs and IndexedDB. The initial setup was straightforward. The hard part was wrapping my head around the mental model shift. Once I stopped thinking about the server as the source of truth, the architecture became much simpler.

Where this goes

I believe local first will become the default for a whole class of apps over the next few years. Users are starting to expect instant responses and offline capability. Developers are tired of paying for server time to proxy simple read operations. The tooling is mature enough to build production apps.

If you are building something new today, at least give local first a serious look. You might find that your app becomes simpler, faster, and more resilient when you put the user’s device first.