Your App Shouldn't Need Wi-Fi to Work: The Case for Local-First Development

Try opening your project management app on an airplane sometime. Or your note-taking tool in a hotel with spotty Wi-Fi. Or your collaborative design software during a cloud outage that's somehow affecting three different vendors at once because they're all running on the same underlying infrastructure.

At some point, you've probably had the uncomfortable thought: why does software that lives on my computer need someone else's server to function?

That question is the seed of a movement that's been growing steadily at the edges of the developer community — local-first software. And while it hasn't broken into the mainstream conversation yet, the teams building in this space are onto something that's going to matter a lot more as the limitations of the cloud-everything model become harder to ignore.

What Local-First Actually Means

The term got its clearest articulation in a 2019 paper by researchers at Ink & Switch, a small industrial research lab that's become something of an intellectual home for this movement. Their definition is worth sitting with: local-first software prioritizes keeping your data on your own device, enabling offline functionality by default, and syncing across devices when connectivity is available — rather than treating the server as the source of truth and the local device as a thin client.

This is a meaningful inversion of how most modern SaaS is built. In the dominant model, your data lives on someone else's server. Your app is essentially a fancy interface for making API calls to that server. Offline support, if it exists at all, is a bolted-on afterthought — a fragile cache that breaks in interesting ways when you reconnect.

Local-first flips that. Your device holds the real data. Sync is additive, not foundational. The app works whether or not there's a connection, and collaboration happens through conflict resolution mechanisms rather than server-side locking.

The Practical Benefits That Are Actually Compelling

Let's talk about what this means in practice, because the philosophy is only interesting if the outcomes are real.

Latency drops to nearly zero for local operations. When your app isn't waiting on a network round-trip to do anything, it feels fundamentally different. Snappier. More responsive. This is why native apps have historically felt faster than web apps even when the underlying hardware is the same — and it's why local-first apps can recapture that feeling even in a web context.

Offline becomes the default, not the exception. This is increasingly relevant as people work across more varied environments. A developer working from a coffee shop with unreliable Wi-Fi, a designer on a flight, a field technician in a building with no signal — local-first software serves all of these users without special-casing.

Vendor lock-in gets a lot weaker. If your data lives in an open format on your own device, switching tools becomes dramatically easier. You're not held hostage by a company's export functionality or their continued existence as a business. This is a bigger deal than it might sound — we've all seen what happens when a beloved SaaS product gets acqui-hired and shut down with 60 days notice.

Privacy gets structurally better. When your data doesn't transit through someone else's servers by default, a whole category of privacy risk simply doesn't exist. This matters more in some domains than others, but for anything touching sensitive personal or business information, the local-first model is fundamentally more defensible.

The Tools That Are Making This Possible

For a long time, local-first development was more aspiration than reality. The hard problem was sync — specifically, how do you handle conflicts when the same data gets modified on two different devices while they're offline?

The answer that's emerged is a family of data structures called CRDTs — Conflict-free Replicated Data Types. The math is genuinely clever: CRDTs are designed so that any two versions of the same data can always be merged without conflicts, regardless of the order operations happened in. You don't need a server to arbitrate. You don't need locks. The merge just works.

Implementations of CRDTs have gotten significantly more accessible in recent years. Libraries like Yjs and Automerge have made it practical to build collaborative, offline-capable applications without needing a PhD in distributed systems. Replicache offers a more opinionated sync framework that handles a lot of the complexity for you. Electric SQL is doing interesting work on syncing Postgres data to local SQLite, which opens up the local-first model to a much wider range of applications.

On the storage side, SQLite's resurgence is directly relevant here. Running SQLite in the browser via WebAssembly — something that's now very much possible — means you can have a real, queryable database living on the user's device, not just a key-value store in localStorage.

Obsidian, the note-taking app that's become something of a cult favorite among developers and knowledge workers, is probably the highest-profile example of the local-first philosophy done well. Your notes are markdown files on your filesystem. Sync is optional and pluggable. The app works completely offline. And a thriving plugin ecosystem has built up around a product that doesn't require you to trust the company with your data.

The Real Tension: Collaboration vs. Sovereignty

Here's where the local-first movement gets genuinely complicated. Real-time collaboration — the Google Docs experience, the Figma experience — is one of the most compelling things cloud software has enabled. And while CRDTs can support collaboration, building a rich collaborative experience on top of them is still non-trivial.

The honest answer is that local-first and real-time cloud collaboration exist on a spectrum, not as binary choices. The most interesting work happening right now is in the middle — systems that default to local, sync efficiently when connected, and support collaboration without requiring you to give up data sovereignty entirely.

Linear, the project management tool that's become popular among developer-focused teams, has invested heavily in making their app feel fast by caching aggressively and syncing in the background. It's not purely local-first by the Ink & Switch definition, but it demonstrates that you can build a significantly better user experience by taking local-first principles seriously even within a cloud-connected model.

Why This Matters for Builders Right Now

If you're building something in 2024 and you're defaulting to the standard SaaS architecture — API server, cloud database, thin frontend client — it's worth at least asking whether local-first could serve your users better.

For certain categories of tools — developer utilities, personal productivity software, creative tools, anything where users work with their own data — the answer might genuinely be yes. The tools exist. The patterns are established. And the users who care about this stuff care about it a lot.

The cloud-everything model has been the path of least resistance for so long that most developers don't even question it. Local-first is a reminder that it was always a choice, not a law of nature. And for the right use cases, it might be the wrong choice.