Local, better, faster, stronger

Personal software the way it should be built — local‑first

15 March 2021

I recently discovered local-first software, which is a manifesto for a different way of building software. Like the mobile-first was meant to make sure that apps and web work well on mobile devices, local-first software aims to make apps work well locally. As with the mobile-first approach, the local-first approach isn’t local-only software. It should still be collaborative and not tied to one device, but the experience of using any app locally should be first class.

The original article, Local-first software: You own your data, in spite of the cloud, outlines the principles of local first software:

1. No spinners: your work at your fingertips
2. Your work is not trapped on one device
3. The network is optional
4. Seamless collaboration with your colleagues
5. The long now
6. Security and privacy by default
7. You retain ultimate ownership and control

I won’t go into detail about the principles here as I think they mostly speak for themselves. To summarize, the main arguments are that using software shouldn’t require a network connection, you should own your data, and the performance of software should be what your device allows it to be. For further details, I highly recommend reading the original article.

Using local-first software feels good

I’ve tried some of the demos presented in the article, used some software that follows those principles (e.g. Bear), and built a simple shopping list app on my own with the same principles (I might share some learnings later). After a decade of using SaaS software (Google Drive, Figma, Jira, Slack, etc.), using local-first software feels snappier, more responsive, and free. Everything reacts instantly, changes don’t need a server response to take effect and a bad internet connection doesn’t affect your flow state.

The response times of software have a huge impact on the software feels to use (ie. UX). According to Nielsen, a response time less than 0.1 seconds feels instantaneous. More than 1.0 seconds breaks the user’s flow of thought, snaps you out of flow state. Most of the time spent online and using modern software happens in the “kinda okay” range of 0.1s to 1s. We’ve gotten so used to mediocre response times that using fast software feels exciting.

There’s also the aspect of owning the data yourself. Some technologies allow each user to have an independent copy of all of the data required. Even if the web server failed or crashed, the data on my devices won’t be lost.

At the beginning of February, Figma was down for two hours and our entire design team was blocked from working or even seeing our designs. In the earlier days of computing when everything was installed locally, that downtime wouldn’t have affected our productivity. Word documents still open when the internet is down.

The other side of owning the data yourself is that you have full control and IPR to your data. It’s possible to build local-first software so that the company that builds the software has no access whatsoever to your data. E.g. Bear app states that they don’t want access to your data at all.

New design problems to solve

Local-first software comes with some design challenges. In the server-client model, there’s a single source of truth: the server. In local-first software, each user has their own source of truth. Handling the different states of updates and connections is something that requires new kind of design considerations. In the end, users shouldn’t need to worry about the technology, but it should still be clear to them what’s going on.

Take the example of a shopping list. I’ve added some items and I know my partner has added some. How do I know if I have received all of my partner’s updates? If some I haven’t received them, what’s gone wrong? When have I last connected to the server or my partner’s app?

I’m still experimenting in using and designing local-first software, but it’s clear that there are some new, interesting challenges to designing great UX.

Local-first is user-centered

User-centered design has been a focal point of the design profession for decades. Local-first software is an extension of it: bring the data closer to the user whenever possible. It feels like the way software should be built. It’s more performant, doesn’t rely on a company staying afloat to use the tool, and you own your data.

There are some limitations, as always, to the technology. For example, computing-intensive apps still require servers, although some interesting alternatives seem to be in development. Also, the required architecture might not suit all sorts of data.

In an era when terms and conditions of a blogging platform might give the service provider full right to use your IPR in whatever they want, there’s a healthy level of anarchy involved in building software where the users own their data. Did I mention, it also feels crazy fast to use?

Further reading

If you’re interested, check out the following links:

• Local-first software: You own your data, in spite of the cloud
• YJs – a JavaSript implementation of a data model
• An introduction to Conflict-Free Replicated Data Types – A fairly technical, but very good introduction to principles behind CRDTs, the data structure that can be used for local-first software
• Bear.app – An amazing note-taking app that follows most principles of local-first software, although in the Apple ecosystem

I might share some experience of building a simple local-first shopping list web app in a later blog post.