Yes a thousand percent! I'm working on this too. I'm sick of everyone trying to come up with a use case to get all my data in everyone's cloud so I have to pay a subscription fee to just make things work. I'm working on a fitness tracking app right now that will use the sublime model - just buy it, get updates for X years, sync with all your devices and use it forever. If you want updates after X years buy the newest version again. If its good enough as is - and that's the goal - just keep using it forever.

This is the model I want from 90% of the software out there, just give me a reasonable price to buy it, make the product good, and don't marry it to the cloud so much that its unusable w/out it.

There are also a lot of added benefits to this model in general beyond the data privacy (most are mentioned in the article), but not all the problems are solved here. This is a big space that still needs a lot of tooling to make things really easy going but the tech to do it is there.

Finally, the best part (IMHO) about local-first software is it brings back a much healthier incentive structure - you're not monetizing via ads or tracking users or maxing "engagement" - you're just building a product and getting paid for how good it is. To me it feels like its software that actually serves the user.

    sqlite3 data.db 'select text from notes'

There is now a great annual Local-first Software conference in Berlin (https://www.localfirstconf.com/) organised by Ink and Switch, and it's spawned a spin out Sync Conf this November in SF (https://syncconf.dev/)

There was a great panel discussion this year from a number of the co-authors of the the paper linked, discussing what is Local-first software in the context of dev tools and what they have learnt since the original paper. It's very much worth watching: https://youtu.be/86NmEerklTs?si=Kodd7kD39337CTbf

The community are very much settling on "Sync" being a component of local first, but applicable so much wider. Along with local first software being a characteristic of end user software, with dev tools - such as sync engines - being an enabling tool but not "local first" in as much themselves.

The full set of talks from the last couple of years are online here: https://youtube.com/@localfirstconf?si=uHHi5Tsy60ewhQTQ

It's an exciting time for the local-first / sync engine community, we've been working on tools that enable realtime collaborative and async collaborative experiences, and now with the onset of AI the market for this is exploring. Every AI app is inherently multi user collaborative with the agents as actors within the system. This requires the tech that the sync engine community has been working on.

Worth a read, and it's had some very active discussions in the past:

https://news.ycombinator.com/item?id=19804478 - May 2019, 191 comments

https://news.ycombinator.com/item?id=21581444 - Nov 2019, 241 comments

https://news.ycombinator.com/item?id=23985816 - Jul 2020, 9 comments

https://news.ycombinator.com/item?id=24027663 - Aug 2020, 134 comments

https://news.ycombinator.com/item?id=26266881 - Feb 2021, 90 comments

https://news.ycombinator.com/item?id=31594613 - Jun 2022, 30 comments

https://news.ycombinator.com/item?id=37743517 - Oct 2023, 50 comments

I've always thought that this article overstates the promise of CRDTs with regard to conflict resolution. For toy cases like a TODO list, yes, you can define your operations such that a computer can automatically reconcile conflicts - e.g. you only support "add" and "mark as complete", and if something gets marked as complete twice, that's fine.

But once you get past toy examples, you start wanting to support operations like "edit", and there generally isn't a way to infer the user's intent there. Like, if my cookie recipe starts with 100g of sugar, and I modify it on my phone to use 200g of sugar, and I modify it on my desktop to use 150g of honey instead of 100g of sugar, there are a bunch of ways to reconcile that:

1. Stick with 200g of sugar, drop the 1.5x honey substitution.

2. Stick with 150g of honey, drop the 2x.

3. Merge them - 300g of honey.

4. Merge them - 150g of honey and 50g of sugar.

There's no way for any automated system to infer my intent there. So you've got to either:

1. Ask the user to resolve the conflict. This means you have to build out the whole "resolve this merge conflict for me" UI and the promise of "conflict-free" has not been fulfilled.

2. Arbitrarily choose an option and silently merge. This risks badly surprising the user and losing changes.

3. Arbitrarily choose an option, but expose the fact that you've auto-resolved a conflict and allow the user to manually re-resolve. This requires even more UI work than option 1.

4. Constrain your data model to only allow representing intents that can be deterministically resolved. In practice I think this is too severe of a constraint to allow building anything other than toy apps.

IMO #1 and #3 are the least-bad options, but I don't think they're consistent with the expectations you'd have for CRDTs after reading this article.

(FWIW, https://automerge.org/docs/reference/documents/conflicts/ is the relevant documentation for their Automerge library. It looks like they've chosen option 3.)

Anything with online dependencies will necessarily require ongoing upkeep and ongoing costs. If a system is not local-first (or ideally local-only), it’s not designed for long-term dependability.

Connected appliances and cars have got to be the stupidest bit of engineering from a practical standpoint.

Interesting to think about the concept of local-first in the age of AI.

Wanting to be able to run AI fully privately, and offline is the reason we created Cactus:

https://github.com/cactus-compute/cactus

Fully open-source, cross-platform & blazing-fast; lets you plug in private AI into any app on your phone.

This was refreshing to read! More apps should be local-first. If the user does not want to sync their data to cloud, they should have that option.

I’ve been building the offline-first (or local-first) app Brisqi[0] for a while now, it was designed from the ground up with the offline-first philosophy.

In my view, a local-first app is designed to function completely offline for an indefinite period. The local experience is the foundation, not a fallback and cloud syncing should be a secondary enhancement, not a requirement.

I also don’t consider apps that rely on temporary cache to be offline-first. A true offline-first app should use a local database to persist data. Many apps labeled as “offline-first” are actually just offline-tolerant, they offer limited offline functionality but ultimately depend on reconnecting to the internet.

Building an offline-first app is certainly more challenging than creating an online-only web app. The syncing mechanism must be reliable enough to handle transitions between offline and online states, ensuring that data syncs to the cloud consistently and without loss. I’ve written more about how I approached this in my blog post[1].

[0] https://brisqi.com

[1] https://blog.brisqi.com/posts/how-i-designed-an-offline-firs...

Personally, I disagree with this approach. This is trying to solve a business problem (I can't trust cloud-providers) with a technical trade-off (avoid centralized architecture).

The problems with closed-source software (lack of control, lack of reliability) were solved with a new business model: open source development, which came with new licenses and new ways of getting revenue (maintenance contracts instead of license fees).

In the same way, we need a business model solution to cloud-vendor ills.

Imagine we create standard contracts/licenses that define rights so that users can be confident of their relationship with cloud-vendors. Over time, maybe users would only deal with vendors that had these licenses. The rights would be something like:

* End-of-life contracts: cloud-vendors should contractually spell out what happens if they can't afford to keep the servers running.

* Data portability guarantees: Vendors must spell out how data gets migrated out, and all formats must be either open or (at minimum) fully documented.

* Data privacy transparency: Vendors must track/audit all data access and report to the user who/what read their data and when.

I'm sure you can think of a dozen other clauses.

The tricky part is, of course, adoption. What's in it for the cloud-vendors? Why would they adopt this? The major fear of cloud-vendors is, I think, churn. If you're paying lots of money to get people to try your service, you have to make sure they don't churn out, or you'll lose money. Maybe these contracts come only with annual subscription terms. Or maybe the appeal of these contracts is enough for vendors to charge more.

Cool to see principles behind this, although I think it’s definitely geared towards the consumer space. Shameless self plug, but related: we’re doing this for industrial assets/industrial data currently (www.sentineldevices.com), where the entire training, analysis and decision-making process happens on customer equipment. We don’t even have any servers they can send data to, our model is explicitly geared on everything happening on-device (so the network principle the article discussed I found really interesting). This is to support use cases in SCADA/industrial automation where you just can’t bring data to the outside world. There’s imo a huge customer base and set of use cases that are just casually ignored by data/AI companies because actually providing a service where the customer/user is is too hard, and they’d prefer to have the data come to them while keeping vendor lock-in. The funny part is, in discussions with customers we actually have to lean in and be very clear on “no this is local, there’s no external connectivity” piece, because they really don’t hear that anywhere and sometimes we have to walk them through it step by step to help them understand that everything is happening locally. It also tends to break the brains of software vendors. I hope local-first software starts taking hold more in the consumer space so we can see people start getting used to it in the industrial space.

There is no reason for every application to have its own sync platform. I suspect this framing came out of mobile apps where there is no composability or modularity between programs.

If you really embrace "local first" just use the file system, and the user can choose from many solutions like git, box, etc.

I hate signing up for your sync just as much as any other SAAS, but it's even more opaque and likely to break.

That’s essentially what I’m trying to make widely available through my projects https://github.com/ibizaman/selfhostblocks and https://github.com/ibizaman/skarabox. Their shared goal is to make self-hosting more approachable to the masses.

It’s based on NixOS to provide as much as possible out of the box and declaratively: https, SSO, LDAP, backups, ZFS w/ snapshots, etc.

It’s a competitor to cloud hosting because it packages Vaultwarden and Nextcloud to store most of your data. It does provide more services than that though, home assistant for example.

It’s a competitor to YUNoHost but IMO better (or aims to be) because you can use the building blocks provided by SelfHostBlocks to self-host any packages you want. It’s more of a library than a framework.

It’s a competitor to NAS but better because everything is open source.

It still requires the user to be technical but I’m working on removing that caveat. One of my goals is to allow to install it on your hardware without needing nix or touching the command line.

In theory, I love the local-first mode of building. It aligns well with “small tech” philosophy where privacy and data ownership are fundamental.

In practice, it’s hard! You’re effectively responsible for building a sync engine, handling conflict resolution, managing schema migration, etc.

This said, tools for local-first software development seem to have improved in the past couple years. I keep my eye on jazz.tools, electric-sql, and Rocicorp’s Zero. Are there others?

I feel like local-first or offline-first can be seen as something catered to niche users when it's brought up in front of strategy or planning folks — they imagine most people having good, reliable internet all the time. The truth is always more frustrating to account for. It is extremely frustrating to see the falloff in functionality in apps when internet is spotty or slow, which happens a lot. Try doing anything in most apps on the subway in New York (where there isn't service in most tunnels) and you'll feel the pain. Or, try doing anything in a crowd and the cell towers are saturated. Fastmail's client won't show you emails without internet, Balatro hangs while it looks for a cloud save, the list goes on and on.

> Local-first apps, on the other hand, have better privacy and security built in at the core.

I love this article, but the section on security raised a lot of questions. What's the model for authorizing access to documents for collaboration? How do you managed keys safely for encrypted data? How do users recover "lost" keys?

Cloud computing models have a lot of security mechanisms built-in. You might not like the model (AWS IAM for example) but at least there's a foundation already in place.

We need a term for a viable business model to pair with local-first tech.

I've been working on Relay [0] (realtime multiplayer for Obsidian) and we're trying to follow tailscale's approach by separating out the compute/document sync from our auth control plane.

This means thats users still subscribe to our service (and help fund development) and do authn/authz through our service, but we can keep their data entirely private (we can't access it).

[0] https://relay.md

I've been building exactly this with SoundLeaf [0] - an iOS client for the excellent open-source Audiobookshelf server. No data collection, no third-party servers, just your audiobooks syncing directly with your own instance.

The user-friendliness challenge is real though. Setting up Audiobookshelf [1] is more work than "just sign up," but once you have it running, the local-first client becomes much cleaner to build. No user accounts, no subscription billing, no scaling concerns. Simple pricing too: buy once, own forever. No monthly fees to access your own audiobooks.

[0] https://soundleafapp.com

[1] https://github.com/advplyr/audiobookshelf

The primary challenge with building local first software is the sync layer. The current 3rd party offerings are not mature. And people have been working on these for a few years. Electric SQL comes to mind.

This reminds me of my own painful story: I once made a local photo search app called Queryable that ported OpenAI's CLIP model to iPhone, letting you search your photos with queries like "a black cat sitting on a sofa."

Since it needed to access users' local photo libraries, I didn't want the app to connect to the internet under any circumstances. So I made it a paid app instead of the usual free+in-app purchases model, since the latter requires calling StoreKit which goes online. But because the app had to run the CLIP model, it would crash on lower-performance phones like the iPhone X. Users who paid for it couldn't use it and felt scammed, leading to tons of one-star reviews and angry complaints about their photos being stolen. Eventually I decided to open-source the app, though it never brought me much revenue anyway.

Two years later, Apple started announcing they'd be integrating this exact feature into Apple Intelligence : )

We have been building a local-first browser app (PWA) for personal finance, based on double-entry accounting. https://finbodhi.com/

We do use online services like firebase for auth, and some service to fetch commodity prices etc, but rest of the data is stored in browser storage (sqlite) and backed to local disk (and soon dropbox). We also syncs data across devices, always encrypting data in transit.

I think it's the way to go, for most personal data applications.

I've been wanting a computing model I call PAO [1] for a long time. PAO would run personal application "servers" and connect dynamic clients across all devices. PAO is centralized, but centralized per user, and operating at their discretion. It avoids synchronization, complex concurrent data structures, and many other problems associated with alternatives. Its weakness is a need for always-on networks, but that complication seems ever easier to accept as omnipresent networks become realistic.

[1] https://tiamat.tsotech.com/pao (2012)

I recently started using Typst instead of Pandoc->LaTeX.

I held off on playing with Typst for years because I was under the (incorrect) impression that the only way to use it was with their web editor. I'm sure that their editor is completely fine, but I am pretty entrenched in Neovim and Pandoc had been serving me well.

Once I found out that Typst has a command line version that I can use directly, it became more appealing, because I'm pretty sick of cloud shit.

It's a very exciting moment for this movement. A lot of the research and tech for local-first is nearing the point that it's mature, efficient, and packaged into well designed APIs.

Moreover, local-first —at least in theory— enables less infrastructure, which could reignite new indie open source software with less vendor lock-in.

However, despite all my excitement about embracing these ideas in the pursuit of better software, there's one hurdle that preventing more wide spread adoption amongst developers, and that is the Web platform.

The Web platform lacks building blocks for distributing hashed and/or signed software that isn't tied to origins. In other words, it's hard to decouple web-apps from the same-origin model which requires you set up a domain and serve requests dynamically.

Service Workers and PWAs do help a bit in terms of building offline experiences, but if you want users to download once, and upgrade when they want (and internet is available), you can't use the Web. So you end up breaking out of the browser, and start using Web technologies outside of the browser with better OS functionality, like Electron, React Native, Tauri et al (the https://userandagents.com/ community is doing some cool experiments in this space).

> "we have gone further than other projects down the path towards production-ready local-first applications based on CRDTs"

This seems like a bold claim, but IMHO Ink & Switch have earned their solid reputation and it wouldn't surprise me if it's true. I agree w/ their analysis and am philosophically aligned w/ their user-centric worldview. So who's going to build "Firebase for CRDTs"?

The data part aside, and specifically on the platform/functionality side - these cloud/large products unfortunately do offer more powerful/advanced features, or convenience. Be it cloud multi-device functionality that makes moving around and collaborating seamless, or to enterprise products like snowflake and fabric that offers all sorts over a standard mssql db.

I'm personally very against vendor lock in, but there is some value to them.

Lately, I have been following this approach and going towards local-first software. I like simple softwares with barebone features.

- Password manager: KeyPassXC

- Notes: Logseq

- Analytics: Plausible

- Media: Jeyllyfin

- Uptime kuma

- Finance tracker: Actual Budget etc is too heavy so I built this. https://github.com/neberej/freemycash/

- Search: Whoogle? is kinda dead. Need alternative.

Remember when the justification for cloud was "Your work is not trapped on one device". Well, turns out your cloud data is trapped on one device, AND it's not under your control.

The old model—a one-time purchase, local install, full user control—worked because devs could sell boxed software at scale. Now, that model collapses unless someone’s willing to either Undervalue their own labour, or treat the software like a public good, absorbing the long tail of maintenance with no recurring income.

The article posits it as though subscription software is something which has been sneaked in on us. But users today expect things like instant updates, sync across devices, collaboration, and constant bug fixes and patches - none of which come easily if you're only willing to pay for the system once.

100% agree! I built Paisley (because it is the opposite of plaid), to host your personal finances locally and is 100% open source. Paisley pulls data from your financial institutions by scraping balances and importing CSV exports, storing everything locally in a simple SQLite database.

https://github.com/patrickcollins12/paisley

What are the top web local first frameworks worth checking out these days? i’ve heard of livestore, tanstack DB with electric, zero. any others that are easy to use and flexible? use case is multiplayer apps and maybe games. thanks!

I've made a local first, end-to-end encrypted, auto sync bookmark extension that doesn't milk your data in any way. It's 100% private, I even don't use Google analytics on my website. Some of the reasons why I've put some work into this is:

  - because I could not find something similar that doesn't milk and own my data
  - to never lose a bookmark again
  - to have my bookmark data encrypted in the cloud
  - to have private history
  - to have some extra time saving features in the extension that are for unknown reason rare to find
  - more learning and experience (it's acutally quite complex to build this)

After about 4 years of using it daily on every pc I own, I found out it's a pain for me and my family when it is not installed on a browser. I thought; if it's useful for us, it might be useful for others too! So, I decided to make it available by subscription for a small fee to cover the server and other costs. I'm not really into marketing, so almost no one knows it exists. You can find it on markbook.io.

Skimming the article, it seems to touch on a lot of the right points, but the motivating first paragraph seems weak:

> Cloud apps like Google Docs and Trello are popular because they enable real-time collaboration with colleagues, and they make it easy for us to access our work from all of our devices. However, by centralizing data storage on servers, cloud apps also take away ownership and agency from users. If a service shuts down, the software stops functioning, and data created with that software is lost.

"Apple pie might be tasty and nutritious and exactly what you want, but, theoretically, apple pie could burst into flames someday, and take your favorite pie-eating bib with it.

Regarding the no-spinners: I think it is the wrong approach to argue that just because you have data locally, you don't need any spinners.

Whether you need a spinner or not should be decided by the User Experience (e.g., when the user has to wait for more than 100ms, show a spinner), and not by the location of the data. I am a big fan of local-first apps and enjoy building them myself. However, sometimes your app takes a moment to load. With local-first, you eliminate the network as a source of delays, but there are other factors as well, such as large data sets or complex algorithms.

For example, when you have a project planning software and want to plan 100 work packages with multiple resource combinations in an optimal way, depending on the algorithm, this can take some time. In that case, a spinner or a progress bar is a good thing.

I love this idea of local-first software, but from a business point of view there's unfortunately no current incentive to adopt it since it's nowhere near as profitable compared to SaaS. That, in my opinion, is the biggest bottleneck right now to this getting worldwide adoption

Most of that stuff was very much over engineered in the last two decades.

The backend for my personal notes, tasks, bookmarks, calendar and feeds are files in directories synced with Syncthing across devices.

I ended there after going from one app to another and being tired of all this.

It is self hosted with no server backend (beyond a Syncthing on a NAS or VPS, optional). It is very reliable and works without Internet connection.

I could have put everything in sqlite too and sync it one way or another, but it seemed already too complicated for my requirements.

I can't share it beyond my close relatives but I had the same problem with people using Google or Microsoft before.

People's personal computers, even their tablets and phones are so powerful, they can fulfill most use cases (except AI), especially if the application is reasonably efficient.

100%! Not only local-first. But also private, zero/minimal dependency, open source and environment agnostic!

If there is anyone interested in working on such projects - let's talk! We can't leave our future to greedy surveillance zealots.

Goal #2, your data is not trapped in a single device is the hard bit, especially with goal #3, the network is optional. For #2 to be true, this means the network is *not* optional for the developer, it is required. Thus the entire complexity of building a distributed app, especially one without a centralized server, which is particularly difficult even with modern local first database tools, greatly increases the complexity of writing this type of software compared to either traditional desktop apps or cloud apps.

Tried to adopt this last month at work, it failed. E.g. the mentioned Automerge, it has poor docs https://automerge.org/docs/reference/library_initialization/... and that left out a lot of question, it seems backend agnostic but have to figure out how to store, how to broadcast ourselves.

Nextcloud with a few addons - all open source - gets you feature parity with all of that lot.

NC itself gets you file sync and webdav etc. An add on gets you the webby version of LibreOffice. You can bolt on AI addons to classify and tag your images/photos and with a bit more effort, your docs too.

It's properly local first.

Didn't this already happen? The internet died 20 years ago. Now it is just ‘somewhat’ interconnected intranets with their own local legislation?

Awesome to see this getting more coverage. I am very interested in local first and I am working on several progressive web apps based around this. One app depends on file sync, not database sync and the best I have found is remoteStorage.js. Its not perfect, but its very much the missing piece I was often looking for.

Synchronize execution. Not data. https://multisynq.io Synchronization of the data is implicit. NO centralized anything.

In a world of owning nothing and paying subscriptions for everything, owning your data and using software that is either yours or libre is 'rebellion' to many a service provider.

Its not local-first or some sort of cloud diet trend, it should be the norm.

The speed alone is sufficient for a local-first approach. The latency of any cloud software I’ve ever used is like constant sand in the gears of thinking. Although taking supplements that slow my thinking—essentially natural downers—do improve my experience with such software, the improved experience comes at the expense of IQ. Basically, you need to be a little slow and dumb for the software to work as intended.

This is nuts. Computers are supposed to enhance and enable thinking, not make you stupid. In this sense, cloud software is possibly the biggest fraud ever perpetrated on the paying, computer-using public.

For the love of God, please bring back my late 1990s and early 2000s brain-boosting computer experience.

Offline-first, now with CRDTs, and a brand new name!

One compromise could be to host the software but also offer the option for self hosting.

That was published 6 years ago. What's the state of the art of local-first software technology in 2025?

One thing I’m personally excited about is the democratization of software via LLMs.

Unfortunately, if you go to ChatGPT and ask it to build a website/app, it immediately points the unknowing user towards a bunch of cloud-based tools like Fly.io, Firebase, Supabase, etc.

Getting a user to install a local DB and a service to run their app (god forbid, updating said service), is a challenge that’s complex, even for developers (hence the prevalence of containers).

It will take some time (i.e. pre-training runs), but this is a future I believe is worth fighting for.

That’s why I’m working on https://collate.one - offline AI workspace

AIs like GPT being non-local is one of my biggest issues with it.

Self hosting (which is often adjacent to local-first software) is fine. I've done it for years.

But it is a nightmare when it goes wrong: the conclusion I've reached is that it is out of reach to regular people who don't want the Byzantine support load that could accompany something going wrong. They want turnkey. They want simple. They aren't interested in operating services, they're interested in using them.

The FLOSS model of self hosting doesn't really offer a reliable way of getting this: most businesses operating this way are undercapitalised and have little hope of ever being any other way. Many are just hobbies. There are a few exceptions, but they're rare and fundamentally the possibility of needing support still exists.

What is needed, imo, is to leverage the power of centralised, professional operations and development, but to govern it democratically. This means cooperatives where users are active participants in governance alongside employees.

I've done a little work towards this myself, in the form of a not-yet-seen-the-light-of-day project.

What I'd love to see is a set of developers and operators actually getting paid for their work and users getting a better deal in terms of cost, service, and privacy, on their own (aggregate) terms. Honestly, I'd love to be one of them.

Does anyone think this has legs to the same extent as local-first or self hosting? Curious to know people's responses.

Databases like Postgres can be run locally or as part of some kind of managed service in the cloud. Anyone know of recent stats that show the percentage of databases that are managed locally vs by some cloud service?

Complete agreement. Here's a brief, practical action plan for Windows users:

  * Download all your data from Microsoft's "OneDrive" cloud storage, which if not disabled, is the default storage method in a new Windows install.
  * Verify that all your files are now stored locally.
  * Click the gear icon, go to "Settings -> "Account" -> "Unlink this PC," right-click, "Unlink account".
  * Remove Microsoft's OneDrive app from your system -- full removal is the only way to prevent perpetual harassment and reactivation. Go to "Apps" -> "Apps & features" (or "Installed apps" on Windows 11) -> "Microsoft OneDrive", right-click, "Uninstall."
  * Optional extra step: cancel your Microsoft 365 subscription and install LibreOffice (free, open-source).

Remember this -- cloud storage only has advantages for Microsoft and law enforcement (which have a number of easy ways to gain access to your documents compared to local storage). For a Windows user, cloud storage is the ultimate Dark Pattern.

yes but think of all those poor shareholders with unmaximized value you heartless man!

With crdt implementations like y.js, writing your own synchronization engine is trivial: https://greenvitriol.com/posts/sync-engine-for-everyone

How about redundancy in general. Not local first, not cloud first, but "anything can be first and last". That's how the "cloud" works in the first place. Redundancy. Mesh networks as well.

[dead]

[dead]

[dead]

Local first is almost equates to both privacy protective and public software good.

Essentially antithetical to capitalism, especially America's toxic late stage subscription based enshittification.

Which means its typically a labor of love or a government org has a long term understanding of Software as a Infrastructure (as opposed to SaaS)