The Local-First Renaissance

Here's the truth: for twenty years, we gave away control of our data for convenience. Now over 3,000 developers are building local-first applications - software that works without asking a server for permission. The best apps I've used lately feel like we've remembered what we forgot.

For two decades, the industry pushed everything to the cloud. Your files. Your notes. Your photos. Your code. The pitch was compelling: access anywhere, automatic backup, no maintenance. The tradeoffs were hidden: latency, outages, and subscriptions. There was also the quiet reality that you don't actually own what you've created.

I've watched this pendulum swing for four decades now. Now developers are building applications that put your data on your device first. Sync is optional. The network is a feature, not a requirement. And surprisingly, this "old" approach feels revolutionary.

What Local-First Actually Means

The term was coined in a 2019 paper by Martin Kleppmann and colleagues at Ink & Switch. Local-first software keeps your data on your devices. The cloud becomes a convenience for sync and backup, not the source of truth.

The principles are clear:

• No spinners. Your data is already there. Operations complete instantly because they don't need network round-trips.
• Works offline. Airplane mode is fine. Bad wifi is fine. The application functions regardless of connectivity.
• Your data, your device. Files live on hardware you control. No vendor can delete your account or change pricing.
• Longevity. You can access your work in twenty years because it's in open formats on your disk, not trapped in a service that might not exist.
• Collaboration without servers. Peer-to-peer sync when possible. Cloud sync when convenient. The server is optional.

This sounds like software from 1995 because it shares the same core assumption: the computer in front of you should actually compute.

Why the Cloud Model Broke

The cloud-first model has accumulated problems that are becoming difficult to ignore:

Latency everywhere. Click. Wait. Spinner. Every action requires a round-trip to servers that might be thousands of miles away. Modern apps feel sluggish despite modern hardware because they're waiting on the network constantly.

Outages affect everyone. When Notion goes down, your notes are inaccessible. When Figma has issues, your designs are frozen. The entire productivity of companies with cloud-dependent workflows stops when a single service has problems.

Subscription fatigue. Software that once cost $200 once now costs $30/month forever. Stop paying and you lose access - sometimes to work you created. The business model treats users as revenue streams rather than customers.

Privacy as afterthought. Your data lives on servers you don't control, subject to terms of service that change without notice. Companies get acquired, policies change, and your data goes along for the ride.

Vendor lock-in intensifies. Migration between cloud services is difficult by design. Your data exists in proprietary formats accessible only through vendor APIs. Leaving costs more than staying. I've written about how serverless architecture deepens this lock-in - cloud-first is the same pattern at the application layer.

These aren't edge cases. They're the normal experience of using modern software.

The Technology That Changed

Local-first wasn't practical at scale until recently because multi-device sync was genuinely hard. If two people edit the same document on different devices, who wins?

The breakthrough is CRDTs - Conflict-free Replicated Data Types. These are data structures mathematically guaranteed to merge without conflicts. Two users editing a document offline can sync later and get consistent results automatically. No server required to arbitrate.

As PowerSync traces in their history of the movement, the Ink & Switch paper called CRDTs "a foundational technology for realizing local-first software." They make the hard part - multi-device collaboration - tractable without centralized coordination.

Other technologies have matured alongside:

• SQLite everywhere. A battle-tested embedded database that runs on phones, browsers, and desktops. Local storage that's actually reliable.
• WebRTC. Peer-to-peer connections directly between devices. Sync without going through servers.
• Improved device storage. Phones and laptops have hundreds of gigabytes. Local data isn't the constraint it was in 2005.

The tooling has reached the point where building local-first applications is realistic for mainstream developers, not just specialists.

The Developer Benefits

At Local-First Conf 2024, Martin Kleppmann made a surprising point. "The benefits to the app developer are perhaps at least as big as those to the end-user."

For developers, local-first simplifies architecture:

No backend to maintain. No servers to provision, scale, or keep running at 3am. The application is the product, not the infrastructure. This eliminates what I call the unnecessary data infrastructure problem - building complexity you don't need.

No sync bugs to debug. CRDTs are mathematically correct. The whole class of sync-related bugs - race conditions, lost updates, merge conflicts - disappears. The framework handles it.

Simpler testing. Test the application locally. No mock servers. No network simulation. The code you test is the code that runs.

Better user experience. Operations are instant because they're local. Real-time collaboration feels real-time because it is. The application is responsive because it's not waiting on network latency.

The tradeoff is learning new paradigms. But for applications where it fits, the simplification is substantial.

What's Actually Being Built

The movement has matured past theory into shipping products:

Linear. The issue tracker that took over developer workflows runs local-first. Changes sync when network allows but work offline by default.

Obsidian. Notes as markdown files on your disk. Sync is a plugin. The files are yours forever in a format you control.

Figma. While still cloud-heavy, Figma's multiplayer architecture was influenced by CRDT research. Local-first principles in mainstream tools.

Notion alternatives. Applications like AnyType and Logseq offer Notion-like functionality with local storage and optional sync.

The pattern: developer tools adopted local-first early because developers care about these tradeoffs. Consumer apps are following as the benefits become obvious.

When Local-First Fits

Local-first isn't right for everything. It excels when:

• Data is personal or team-scoped. Notes, documents, designs, code - data that belongs to individuals or small groups rather than being globally shared.
• Offline capability matters. Mobile apps, field applications, travel tools - anything used where connectivity isn't guaranteed.
• Latency sensitivity is high. Creative tools, gaming, real-time collaboration - applications where waiting on the network breaks the experience.
• Privacy is important. Sensitive data that shouldn't live on third-party servers. Legal documents, health information, financial records.
• Longevity matters. Archival data, personal knowledge bases, creative work - things you want accessible in decades, not dependent on a startup surviving.

It fits less well for:

• Global shared state. Social networks, marketplaces, multiplayer games - data that is inherently centralized.
• Heavy computation. Applications that genuinely need server-side processing power.
• Large datasets. When data exceeds what devices can reasonably store locally.

The question isn't "local-first or cloud" but "what should be local and what should be cloud?" Most applications benefit from being more local than they currently are. This ties into a broader principle: your database might be all the API you need when data stays local.

Local-First Fit Assessment

Check which characteristics apply to your application:

The Cultural Shift

Beyond technology, local-first represents a philosophical position: users owning their data and controlling their tools.

This cuts against twenty years of industry direction. Subscription models want recurring revenue. Cloud platforms want lock-in. Investors want network effects. Local-first says: maybe the user's interests should come first.

The community has grown substantially. According to the Local-First Web community, over 3,000 developers are now actively building local-first applications. They've hosted 20+ meetups since 2022. The movement is small but accelerating.

One developer described the current state as "comparable to React in 2013" - technically promising but still early. Libraries are young. Best practices are emerging. But the trajectory is clear.

What This Means for Your Work

For those building software:

The cloud default is worth questioning. Does this data actually need to live on a server? Does every action need a network round-trip? The answer might be no more often than assumed.

The tools are maturing. Automerge, Yjs, and other CRDT libraries are production-ready. SQLite runs everywhere. The building blocks exist.

Sync-first architectures tend to be cleaner. Build the application to work locally first. Add sync as a feature rather than a requirement. This order simplifies the architecture.

For those choosing software:

Data portability matters. Can data be exported in open formats? Will files work without the application?

Offline behavior reveals priorities. Turn off wifi. Does the application work? How long until it needs the network?

Longevity is undervalued. If this company disappears, is the work lost? Is there a migration path?

"Local-first isn't about rejecting the cloud. It's about putting your devices, your data, and your experience first."