Local-First Software: Why Your Tools Should Work Without the Cloud

You've felt it. The app you depend on goes down for "scheduled maintenance" at the worst possible moment — the night before a deadline, the morning of a launch, the one afternoon you actually had blocked off to get real work done. You stare at a spinner, or a 502 page, or a cheerful status tweet about "investigating an issue," and you wait. Because you have no choice. Your data is on their server, the app is a thin client, and without their server being up, you have nothing.

Or maybe it's the other version. The company gets acquired, and eighteen months later the product you built your entire workflow around gets sunset. A blog post goes up thanking the community, the export window opens for thirty days, and then it's gone. The thing you used every day for three years is now a redirect to a landing page for something you don't want.

Or the pricing version. The tier you were on — the one that made sense for a solo operator or a small team — disappears. The feature you used is now locked behind a plan that costs three times as much. You can pay it, or you can leave. But leaving means leaving your data behind, because the export is a CSV that lost half the relationships, or an API that rate-limits you into next week, or a format nothing else can read.

This is the cost of cloud-dependent software, and people are starting to push back.

There's a name for the pushback. It's called local-first, and I think it's one of the more important ideas in software architecture right now — not because it's new (it's actually the oldest idea in computing), but because we collectively forgot it during the SaaS gold rush, and we're remembering it now that the bill is coming due.

What "Local-First" Actually Means

The term "local-first" comes from a 2019 research paper out of Ink & Switch, the research lab founded by the team behind Evernote. The paper, "Local-first software: You own your data, in spite of the cloud," laid out a set of principles for a different way of building software. The idea was simple in spirit and hard in execution: what if the software you use every day treated your device as the source of truth, and the cloud as an optional convenience?

Here are the core principles, as I think about them:

Your data lives on your device first, cloud second. Not "synced to the cloud and cached locally." Locally first. The local copy is the real copy. The cloud copy is a replica.

The app works without an internet connection. Not "degrades gracefully." Works. You can open it, read your data, edit your data, create new data, and close it, all with the wifi off, and nothing breaks.

The cloud is for sync and collaboration, not a requirement for basic function. This is the key distinction. The cloud is a feature, not a dependency. It's there when you want it and absent when you don't.

You own your data. No vendor can lock you out of it. If you stop paying, if the company folds, if you get banned for some terms-of-service violation you didn't know you committed — your data is still on your machine, in a format you can read.

It's worth contrasting this with the two architectures on either side of it.

Cloud-first is what most SaaS is. The data lives on a server. The app — whether it's a web app, a mobile app, or an Electron wrapper — is a thin client that fetches and renders. If the server is down, or your network is down, or your session expires, you have nothing. You're renting access to your own data.

Local-only is the other extreme. Think of an old desktop app from the 90s, or a SQLite database file you open with a script. Everything is on your machine. There's no sync, no collaboration, no multi-device. It works forever, but it's isolated. If your hard drive dies and you didn't back up, it's gone. If you want to work on your laptop and your desktop, you're copying files around manually.

Local-first is the synthesis. You get the permanence and ownership of local-only, plus the convenience of cloud sync — but the sync is additive, not foundational. Take the sync away and the app still works. Take the cloud away and you still have your data.

The Problems Local-First Solves

Let's get specific about what's actually broken in cloud-first software, because the principles above are abstract and the problems are concrete.

Uptime Dependency

Here's a fun fact about cloud apps: they can break in two places. Your network can go down, which means you can't reach the server. Or their server can go down, which means the server can't reach you. Either way, you're staring at a spinner. You have no control over either failure mode. You can upgrade your internet plan, but you can't make AWS us-east-1 stop having a bad day.

Local-first apps break in one place: your machine. If your machine is on, the app works. That's it. No dependency on a network you don't control, no dependency on a server you can't see. The blast radius of a failure shrinks from "the entire internet between you and a data center" to "the laptop in front of you."

I'm not saying local machines never fail. They do. Hard drives die, batteries swell, coffee spills. But when a local machine fails, it's one person's problem, and it's a problem with a known solution (a backup, a new machine, a sync copy on another device). When a cloud service fails, it's everyone's problem simultaneously, and the only solution is to wait.

The Sunset Problem

This is the one that actually scares me, because it's not hypothetical. It happens constantly.

A company builds a tool. People adopt it. People build workflows around it, put years of data into it, integrate it into their daily lives. Then the company runs out of money, or gets acquired by someone who wants the team not the product, or pivots to "enterprise AI solutions" or whatever the current pivot fashion is. The product gets sunset.

When a cloud-first app shuts down, you lose everything. The server turns off, the app stops working, and your data — which lived on that server — is gone. Maybe you get an export. Maybe the export is usable. Maybe you have thirty days to figure it out. Maybe you don't.

When a local-first app shuts down, you lose updates. That's it. The app you already installed keeps working. Your data, which lived on your machine, is still on your machine. You can keep using the tool indefinitely — you just won't get new features or bug fixes. Eventually, maybe, OS updates will break it, and that's a real problem. But "eventually this might stop working" is a very different proposition from "this stops working on March 31st and all your data goes with it."

There's a graveyard of cloud apps that took people's data with them. Google Reader. Sunrise. Workflowy's old pricing model (not a sunset, but a "your data is now behind a paywall" moment). Every small SaaS that ever ran out of runway. Local-first is structural protection against this. You can't be sunset out of your own data if the data was never on someone else's server.

Pricing Leverage

Cloud SaaS has a particular kind of leverage that I think people don't think about enough: it holds your data hostage.

I'm not saying SaaS companies do this maliciously. Most don't. But the architecture gives them the leverage whether they use it or not. If you stop paying, they can turn off your access. And "access" here means "the ability to open, read, and use the data you've spent years creating." The export feature is a valve they control. They can make it good, or they can make it a CSV that strips out every relationship and attachment. They can give you 30 days, or they can give you none.

Local-first removes this leverage entirely. If you stop paying for a local-first app, the app keeps working. You keep your data. You keep the ability to open it, read it, edit it. What you lose is the sync, the updates, the premium features — the stuff that's actually worth paying for, as opposed to the stuff you're paying for because you have no choice.

This isn't anti-SaaS. I pay for plenty of SaaS. But I'm aware, every time I do, that I'm renting access rather than owning a tool. Local-first is about owning the tool. The business model has to be different — you charge for the software, or for the sync, or for updates — but the relationship with the user is healthier. The user is a customer, not a hostage.

Privacy and Compliance

Your data doesn't flow through someone else's servers. That's not just a philosophical point. It's a legal and operational one.

If you're working with data that's subject to GDPR, HIPAA, SOC 2, or any of the alphabet soup of compliance regimes, every server your data touches is a liability. Every SaaS in your stack is a vendor you have to assess, a data processing agreement you have to sign, a breach surface you have to worry about. Cloud-first software multiplies these surfaces. Every tool is another place your data lives, another company that could have a breach, another sub-processor in your flow-down.

Local-first software shrinks these surfaces. If your data stays on your machine, it doesn't touch anyone else's infrastructure. There's no vendor to assess for the core functionality. If sync is optional and you don't use it, there's no data flowing anywhere. If you do use sync, you've made a deliberate choice about where your data goes, rather than having it flow to a server by default because the app doesn't work otherwise.

There's also just the matter of basic dignity. I don't think every note I write, every query I run, every file I open needs to be visible to a company that might use it to train a model, or sell aggregate analytics, or hand it over in response to a subpoena I'll never hear about. Local-first is a way of keeping your work your business. Not because you're doing something wrong, but because it's yours.

Performance

This one is underappreciated, and it's becoming more important as people notice how slow "modern" software feels.

A cloud app does a network round-trip for basically everything. You click a thing, the app sends a request to a server, the server queries a database, the database responds, the server responds, the app re-renders. That's milliseconds — tens to hundreds of them, depending on where the server is and how many hops are involved. Add a cold connection, a TLS handshake, a DNS lookup, and you're into seconds. We've all used apps where clicking a tab takes a full second. That's not because the app is complex. It's because the app is far away.

A local-first app does operations in microseconds. The data is right there. The disk is right there. The CPU is right there. There is no round-trip because there is no trip. This is why local-first apps feel fast in a way that cloud apps, no matter how well-optimized, can't quite match. It's not about engineering effort. It's about physics. Light is fast, but your local memory bus is faster.

This matters more than people admit. Speed is a feature. The difference between an app that responds in 10ms and one that responds in 200ms is the difference between an app that feels like an extension of your hands and one that feels like you're making requests and waiting for replies. Local-first gets you the former by default.

The Tradeoffs (Be Honest)

I'm not going to pretend local-first is free. It's not. The reason cloud-first won for a decade is that it's easier to build, easier to monetize, and easier to scale. Local-first asks you to solve some genuinely hard problems.

Collaboration is harder. In a cloud-first app, collaboration is easy because there's one server and one source of truth. Two people edit a document, the server merges the edits, done. In a local-first app, two people have two local copies, and those copies need to converge. That's a distributed systems problem, and distributed systems problems are famously not easy. You need conflict resolution. You need a way to merge concurrent edits without losing data or corrupting state. This is where CRDTs (Conflict-free Replicated Data Types) come in, and CRDTs are a real research area, not a drop-in library you can use without understanding.

Multi-device requires sync. If you want your data on your laptop and your phone and your desktop, something has to move it between them. That something is a sync layer, and sync is one of those things that sounds simple until you try to build it. What happens when two devices edit the same record while offline? What happens when a device comes back online after a week? What happens when the sync server is down? These are solvable problems — tools like Automerge and Yjs exist specifically to solve them — but they're problems you have to solve, not problems the architecture solves for you.

No real-time multi-user editing out of the box. Without a sync layer, two people can't edit the same data simultaneously. They can each have their own copy, but they can't see each other's changes in real time. If you want Google Docs-style concurrent editing, you need to build it (or use a library that does). Cloud-first apps get this for free because the server is the shared view. Local-first apps have to construct it.

Updates are your responsibility. In a cloud-first app, the vendor updates the server and everyone gets the new version instantly. In a local-first app, the update has to go to each client. Auto-updaters handle this, but they're another thing to build and maintain, and users can decline updates (which is good for ownership but bad for the vendor who wants everyone on the latest version). There's also the long-tail problem: if you ship a data migration in version 3, you might have users on version 1 for years, and you have to handle their data when they finally upgrade.

These are real tradeoffs. They're why not every app should be local-first, and why cloud-first isn't going away. But they're also tradeoffs that the ecosystem is getting better at handling. CRDT libraries are maturing. Sync infrastructure is becoming commoditized. The cost of building local-first is dropping, while the cost of cloud-first (both the dollar cost and the dependency cost) is becoming more visible.

Local-First in Practice: Who's Doing It

This isn't a theoretical movement. There are real products built on local-first principles, and some of them are widely used. Here are a few I pay attention to.

Obsidian is probably the most visible local-first success story. It's a note-taking app that stores everything as plain Markdown files in a folder on your machine. You can open that folder in any text editor. You can sync it with Dropbox, iCloud, git, or Obsidian's paid sync service. The app works completely offline. If Obsidian the company disappeared tomorrow, your notes would still be there, in Markdown, readable by everything. This is local-first in its purest form, and it's why a lot of people who left Evernote and Notion landed there. The data is yours in a way that data in a hosted wiki never is.

Linear is a partial example, and an interesting one. Linear is a project management tool — issue tracking, basically — and it's cloud-backed. But it's engineered to feel local-first. The app caches aggressively, operations are optimistic, and the UI responds before the server confirms. It's not truly local-first (if their server is down, you can't do much), but it demonstrates that you can apply local-first principles to the experience even within a cloud architecture. The speed and responsiveness are a direct result of treating the local state as primary and the server as a sync target.

Reflect is a notes app built on a CRDT sync layer. It's local-first with multi-device sync built in. Your notes are on your machine, they sync across devices, and the sync handles conflicts automatically. It's a good example of the "local-first plus sync" model — you get the ownership of local and the convenience of cloud, and the hard part (conflict resolution) is handled by the sync infrastructure.

BaseVolt is the one I'm closest to, since I work on it. It's a desktop database admin panel — think of it as a local-first alternative to web-based database tools. You connect it to your database (which might be a local SQLite file or a remote Postgres server), and it runs on your machine, offline, with your queries and connection details never flowing through a third-party server. There's optional cloud sync for things like saved queries and connection configurations across devices, but the core tool works without it. I bring it up not because this essay is about BaseVolt — it's not — but because it's an example of local-first applied to a category (database tooling) that has almost entirely gone cloud-first, and where I think that shift was a mistake.

The broader CRDT ecosystem is the enabling layer. Automerge, Yjs, and similar libraries are making it practical to build local-first apps with real-time collaboration. A few years ago, if you wanted two people to edit the same data offline and merge cleanly, you basically had to do original research. Now you can use a library. This is the infrastructure change that's making local-first viable for more than just single-user tools, and it's why I think the next few years will see more local-first products in categories that currently seem to require a cloud backend.

Why This Matters for Database Tools Specifically

Let me zoom in on the category I know best, because I think it illustrates the broader point.

Database admin panels — the tools you use to look at your database, run queries, browse tables, manage schemas — have almost all moved to the cloud. You log into a web app, you connect it to your database, and you work through a browser. The web app talks to your database. Your queries go from your browser to their server to your database and back.

Think about what that means. You've just added a third party to a path that should be two parties: you and your database. Every query you run goes through someone else's server. Your connection credentials might be stored on that server. Your query history lives on that server. The results of your queries — which might contain customer data, financial records, health information, anything — flow through that server on their way back to you.

This is the architecture that local-first argues against, and in the database case, the argument is especially clear. Your database might be local (a SQLite file on your machine) or remote (a Postgres instance on AWS), but the interface — the thing you're using to interact with the database — doesn't need to also be a hosted service. A desktop app that connects directly to your database, runs queries locally, and renders results locally is simpler, faster, more private, and more robust than a web app that routes everything through a SaaS backend.

There's a security argument here too. Every SaaS database tool is a potential exfiltration point. If the tool is compromised, the attacker might get access to every database its customers have connected. We've seen this pattern in other SaaS categories. A local-first desktop tool that stores connection details locally and connects directly to the database removes that surface entirely. There's no intermediary to compromise because there is no intermediary.

I'm not saying web-based database tools are evil or useless. They exist for good reasons — zero install, easy sharing, cross-platform by default. But I think the default assumption that "database tool = web app" is wrong, and I think it's going to shift. The convenience of a web app isn't worth routing your database traffic through a third party, and once you've used a local-first database tool that connects directly and responds instantly, the web-app version feels like working through a straw.

How to Evaluate Whether a Tool Is Actually Local-First

"Local-first" is becoming a marketing term, which means it's going to get diluted. Products that cache a little data locally will call themselves local-first. Products that have an offline mode for reading will call themselves local-first. So here's a checklist I use, and that I'd suggest you use too, when someone claims the label.

Does it work with no internet? Not "can you read cached data." Can you do the core thing the tool does — create, edit, save — with the network completely off? If the answer is "you can view but not edit" or "you can edit but it won't save until you're online," that's not local-first. That's offline-tolerant cloud-first, which is better than nothing but not the same thing.

Is your data stored in a format you can access without the app? Plain files (Markdown, JSON, SQLite) are ideal. A proprietary local database that only the app can read is better than a remote server, but it's not fully local-first — if the app breaks and the format is undocumented, you're stuck. The gold standard is data in a format that any reasonable tool can open. Markdown, CSV, SQLite, JSON. Formats that outlive any single app.

If the company disappears tomorrow, can you still use the tool? This is the sunset test. If the company shuts down, deletes their servers, and stops existing, do you still have a working app and your data? For a true local-first app, the answer is yes — you lose updates and sync, but the app and data persist. For a cloud-first app with offline caching, the answer is no — the app is a client for a server that no longer exists.

Is the cloud optional or required? Specifically: is the cloud used for sync and collaboration (optional, additive) or for auth and data storage (required, foundational)? If you have to log in to use the app, the cloud is required — auth is a cloud dependency. If your data is stored on a server and the local copy is a cache, the cloud is required. If the app works fully without an account and without a connection, the cloud is optional.

A tool doesn't have to pass all four to be useful. But a tool that passes all four is local-first in the sense I mean here, and a tool that calls itself local-first but fails the sunset test is using the term as marketing.

The Future

I don't think local-first is going to replace cloud SaaS. That's not the claim. Cloud-first is the right architecture for a lot of things — anything where the data is fundamentally shared and real-time (a multiplayer game, a live dashboard, a customer support queue), anything where the compute is heavier than a client can do (large-scale analytics, ML inference), anything where the value is in the network (marketplaces, social platforms). For these, the cloud is the product, not a feature.

But for a large and underserved category of tools — notes, code editors, database management, file management, personal knowledge bases, design tools, writing tools — local-first is the better architecture. These are tools where the data is primarily yours, where the work is primarily solo or small-team, where the core operation is local by nature (editing text, running a query, organizing files), and where the cloud adds convenience without adding fundamental capability. For these tools, routing everything through a server is a tax you pay for no reason, and local-first removes the tax.

The main historical objection to local-first was sync. "Local-first is great for single-user, but the moment you need collaboration or multi-device, it falls apart." That objection was valid in 2015. It's less valid now. The CRDT ecosystem — Automerge, Yjs, and the growing body of patterns around them — is making sync a solved-enough problem that a small team can build a local-first app with real-time collaboration without doing original distributed systems research. The infrastructure is commoditizing. The cost curve is bending.

I think we'll see local-first move from a niche philosophy to a mainstream architecture choice over the next few years, the way "offline-first" did for mobile apps a decade ago. Not everywhere, but in the categories where it fits. And I think the users who adopt local-first tools now will be the ones who, five years later, still have their data — because it was on their machine, in a format they own, in an app that didn't need permission from a server to work.

That's the bet, anyway. The cloud isn't going away. But the idea that every tool needs a server to function — that's going away, and not a moment too soon.

Bottom Line

You should care about local-first because it changes who owns your work. Cloud-first software rents you access to your own data, and the landlord can raise the rent, evict you, or demolish the building. Local-first software puts your data on your machine, in a format you control, in an app that works whether or not anyone's server is up. You pay for the tool, not for access to yourself.

This isn't a niche concern. It's the difference between renting and owning, applied to the tools you use every day. And it's becoming practical — the sync infrastructure is maturing, the tools are getting better, and the cost of cloud dependency is getting harder to ignore.

If you work with databases, this matters doubly. Your database tool shouldn't be another party between you and your data. It should be a direct connection — local, fast, private, and yours.

Try it at basevolt.app — no signup, no credit card.

If you want to argue about any of this, or you're building something local-first and want to compare notes, find me on X.