Local-first Applications are Coming Back

20 years ago, all apps were designed for local work. As the cloud mania hit, many of them adopted data synchronization and collaboration at the cost of being AWS-dependent. Recently, the hype started to cool down, and the local-first software is proliferating, again.

Here, I will outline the concept of local-first apps, offer the motivation for users to choose them, and provide historical context. For a technical deep dive, I recommend the “Local-first software” essay ↗.

How it started

Personal computers were adopted before a stable broadband connection was available worldwide, and software developers had to adapt. Everything was designed around local work, and cloud-related features were optional, not mandatory.

Rise of the cloud

As the Internet became widespread, the latency started to be measured in milliseconds, the unlimited plans became (relatively) cheap, and smartphones were invented, we entered the Cloud Era of the software.

Tech people quickly realized that the cloud is the next big thing, and the world was introduced to Evernote and Dropbox, arguably the two most impactful consumer apps of the decade. Interestingly, both Dropbox and Evernote Web were launched the same year iPhone 3G was released, in 2008. Right time, right place.

B2B and collaboration

As more and more services started as cloud-native, a lucrative market was discovered.

The first app with real-time collaboration that “made it” was Google Docs. It showed us all how collaborative software can look like, with nifty features like multiplayer, read-only mode, and reviewing flow. Suddenly, everyone realized that this is the future of work.

It was also clear now that all those cloud apps should charge teams while keeping their personal offerings gratis. Products that failed to transition to a B2B-centered business model are struggling, as the average user expects every single app to be free.

Now, activities that were traditionally single-player, like design, coding, and writing, are moving to the cloud. With things like Mighty ↗, your entire workplace can live in the cloud. Shift to remote work only accelerated the transition.

Why go local-first

In the age of remote work and interconnectedness, why optimize for local work? As the cloud eats the world, why go another way? From the individual’s point of view, there are a few reasons.

Unreliable connection

It’s 2022, and the network connection is still unreliable. It works most of the time, but when it doesn’t, you don’t want your whole work to be blocked. Network disruption can destroy context and kill the flow. If I would use something like Notion to write these words and see that the network is down, I’d be at least cautious. Instead, I don’t even know whether I have a connection, since I don’t need one. I can focus on writing.

You might have a good connection at home, or maybe even a second provider for redundancy. But if you want to work from a cafe, coworking, taxi, airport, or even a plane, nothing can beat software designed for offline.

Control over data

Yes, the software doesn’t need to be local-first to provide agency of your data. But there’s a high correlation. SaaS services have less incentive to use open formats and provide reliable data export options.

Also, a service can screw up and lose your data forever. By using local-first applications, you have full control at all times.

Privacy

Since your data is stored in the cloud a.k.a. someone else’s computer, that “someone else” has full access to your data. Sometimes, a product can offer data encryption, but often you don’t have a choice.

With local-first apps, you decide what to encrypt, how to do it, and where to store your backups.

Outage

It seems like with each year we get more outages, not less. When a large hosting provider (AWS, GCP, Azure) goes down, it takes everything with it.

By using local-first apps, you might not even notice an outage.

Account suspension

This is mostly relevant to services from Google, Facebook, and other tech goliaths, but it may happen with any provider. One day, you try to log in, but fail to do so. You open Gmail to see any news… oh wait, that doesn’t work too. It’s Google who blocked you then.

With local-first software, there’s nobody to block your account.

Shutdown

Finally, a service might go bankrupt and shut down permanently. Best case scenario, you find a decent alternative and migrate your data. Worst case scenario, you lose your data completely.

Even if the creator of a local-first app stops making new releases, you still can use the app as long as you want.

Local vs cloud

Now, going local-first doesn’t mean letting go of cloud features. For example, a storage provider can sync your data across devices, and provide a backup, versioning, and end-to-end encryption.

Some features of cloud-based services are harder to replicate, like real-time collaboration. Hopefully, there is a tech available ↗ that helps with it. Besides, it may be redundant for your workflow. Do you need a real-time sync when working asynchronously?

How it’s going

Just a few years ago, so much software was cloud-native, that it felt like nothing works offline anymore. Yet, even at the top of the hype, lots of “heavy” apps designed to be utilized for hours mainly operated without a network connection. This includes IDEs, photo and video editing software, music creation apps, and more.

And I believe we’re on the verge of the local-first renaissance in many other areas. Local-first note-taking apps, developer productivity tools, and email clients thrive in recent years.

Cloud-focused knowledge management systems like Evernote, Notion and Roam Research were rendered obsolete by tools like Muse ↗, Logseq ↗, and Athens Research ↗.

Web-based developer utils can live and operate locally with apps like Raycast ↗ and DevUtils ↗.

I may be biased, but I see more and more knowledge management and productivity apps embrace offline work.