Local-First Is Here, Loudly: Why Three of My Products Made the Switch

For years I dismissed local-first software as an ideology project. Correctness-obsessed researchers writing papers about CRDTs while the rest of us shipped server-first apps that worked fine for most users. I was not opposed to it. I just thought it was a framework that would arrive in about ten more years, after the hard sync problems got solved.

Three of my products in the last twelve months have adopted local-first patterns. The reasons had almost nothing to do with the reasons the manifestos talk about.

What finally tipped

Three shifts in the ecosystem, all in the last two years.

Storage APIs in the browser finally grew up. OPFS (Origin Private File System) works now. IndexedDB has stopped feeling like a hostage situation. The File System Access API, for the cases where you need real disk access, has shipped in most browsers that matter. None of this was true three years ago. Now it is.

CRDT libraries became usable by non-PhDs. Automerge 2.x, Yjs, Loro, the whole generation of libraries that hit stable in 2024-2025. I am not a distributed-systems researcher. I can now ship a CRDT-backed feature without reading any papers. That is a profound shift in the ergonomics of this space.

Sync protocols stopped being bespoke. The rise of sync engines that are actually reasonable to use, like ElectricSQL and Instant, meant I no longer had to design my own sync layer. Sync is the hardest part of local-first, and having decent off-the-shelf options changed the math.

Once all three were true, local-first stopped being a research project and started being a product decision. I made it for three products in the last year and each time for a reason that was not about sovereignty or offline ideology.

The boring reasons I actually adopted it

The manifestos talk about user ownership, privacy, offline access. Those are real benefits. None of them were the reason I switched.

The reasons I switched:

Infrastructure costs dropped. A tool with 5,000 users on a traditional stack means a server handling 5,000 sessions, a database with 5,000 user rows, maybe a cache layer, definitely a bill. The same tool local-first means a mostly-static site, a smaller sync server, and a bill that scales with sync bandwidth rather than active sessions. My compute bill for one of the three products I migrated went from $180/month to $18/month. That was enough motivation by itself.

The abuse surface shrank. A traditional SaaS with a database of user-submitted content is an attractive target for spam, scraping, and automated attacks. A local-first app where content lives on the user's device and the server only sees sync payloads is a meaningfully smaller target. I had one product that was spending more time on anti-spam than on features. Going local-first made the spam problem nearly disappear because there was no central content pool to spam into.

The UX during bad networks became dramatically better. Not just for offline users. For anyone on a flaky connection, a local-first app is dramatically faster because reads and writes hit local storage first. The sync happens in the background. The user never sees a spinner for something that should feel instant. I had not realized how many of my churn reports were network-related until I fixed it at the architecture level.

Sovereignty was a nice bonus. The three above were the actual drivers.

What is still hard

Local-first has absolutely not solved every problem. The three hardest ones I hit:

Multi-device conflict UX. When the same user edits the same thing on two devices that both went offline, the CRDT library will merge correctly, but the merge is not always what the user wants. Showing the user a readable version of "these two edits conflicted and here is the result" is a UX problem that nobody has fully nailed. I ship pragmatic solutions (last-write-wins for simple fields, three-way diff with manual resolution for complex fields) and live with some user confusion.

Initial-load time on large datasets. A first-time user on a local-first app that needs to hydrate the full dataset faces a cold-start penalty a traditional app does not. I now ship with progressive hydration: load the most recent 30 days first, stream the rest in the background. This is more code than the server-rendered alternative.

Server-side queries on sync'd data. If you want to do analytics or run a cron job over all users' data, the fact that the canonical copy lives on their devices is suddenly inconvenient. You need to either keep a shadow copy on the server (which partially defeats the point) or build your analytics to work with eventually-consistent server views. I have gone with the shadow-copy approach for one product and the eventual-consistency approach for another. Both have trade-offs.

None of these are deal-breakers. All of them are things you now have to think about instead of getting for free from a traditional stack.

When I would not use local-first

I still do not use local-first for everything. Three cases where I default to traditional:

When collaboration is the core primitive. A real-time collaborative doc is harder local-first than server-authoritative. The sync engines are getting there but they are not quite there for the hard collaboration UX yet. I would still build a Figma clone server-first.

When the data model is fundamentally shared. A ticketing system, a comment thread on a public post, a leaderboard. These are things where the central copy is the source of truth and individual users are just viewers. Forcing them local-first creates complexity for zero benefit.

When regulatory requirements mandate server-side audit. Some products need to be able to say "here is exactly what was in the database at timestamp X." Local-first can approximate this but is harder to prove. Sometimes the answer is just "keep it traditional."

The prediction

Local-first is going to eat a chunk of the SaaS stack in the next three to five years. Not all of it. The chunk where the user's device is the natural home of the data. Personal knowledge management. Writing apps. Productivity tools. Personal finance. Creative tools. Anything where the user is the primary stakeholder of their own content.

The products that will resist longest are the ones built around network effects or public artifacts. Those will stay server-first because that is correct for them.

Anything in the middle, where the current architecture is server-first by default but could reasonably be local-first, is about to have that conversation. The migration path is not trivial but the tooling is finally good enough that a small team can do it in a quarter.

What this means if you are building

If you are starting a new product in 2026, ask yourself whether the data belongs more to the user than to the service. If it does, default to local-first. The infrastructure savings and UX improvements are large enough that you do not need the ideology benefits to justify the choice.

If you have an existing product with a "user content lives in our database" model, it is worth an hour of whiteboarding to see whether local-first would simplify your architecture. You might find that the thing you have been calling "our moat" is actually "a hosting bill we could delete."

The manifestos turned out to be right, just for the wrong reasons.