What Local First Software Is

Local first is a design principle rather than a product category. The short version is that your device holds the primary copy of your data, the application works fully without a server, and any synchronisation is an optional extra rather than the thing that makes it work.

It sounds like a privacy feature. It is more fundamental than that, and understanding why explains a lot about how software gets built.

Cloud first is the default

Most software is built the other way round. Your data lives on someone else's computer. Your device keeps a copy that is really a cache, useful only while the connection holds up.

This design has real virtues. It makes multi-device work almost free, because the server is the meeting point. It makes collaboration straightforward. It means a lost laptop is an inconvenience rather than a disaster.

But it makes one thing unavoidable: the provider can read your data, because your data is on their disk and the software they wrote is running on it. Every capability that follows from that, sharing, export, deletion, portability, exists only because some team had to build it deliberately.

What changes when the device is primary

Put the primary copy on your own machine and a series of things follow automatically, without anybody deciding to offer them:

• It works with no connection. Not as a degraded mode. Fully.
• There is no account. Nobody needs to identify you to give you access to data already on your disk.
• There is no server breach. There is no database of yours to leak, because there is no database.
• Export is trivial. The files are already in a format you can open, because your own software wrote them.
• It keeps working. If the developer stops, quits or the company shuts down, the software does not stop with them.
• It is fast. No round trip for an ordinary action.

Notice that most of these are not features somebody implemented. They are consequences of a different starting point. That is what makes local first an architectural decision rather than a settings toggle.

The honest costs

Any article that only lists the benefits is marketing. Here is what you actually give up.

• Multi-device is hard. Keeping two machines in step is genuinely difficult engineering. If an app offers sync, it is doing real work behind the scenes, and it is the part most likely to have conflicts.
• Backups are your problem. If your disk dies, the data goes with it. A cloud provider is doing your backups whether you thought about it or not. This is the single strongest argument for cloud software and it deserves a straight answer.
• Setup does not follow you. Installing on a new machine means installing, not signing in.
• Some things need a server anyway. Collaboration, sharing a document with someone and processing that needs a computer larger than yours are not solvable locally. Tools that claim otherwise are describing a prototype.
• Nothing is shared unless you share it. Less convenient for teams, better for you.

If you never lose your laptop and never use two machines, local first is strictly better. If you do those things, it is a trade rather than a free win.

Privacy is not the same thing

Local first gets you most of the way, and it is worth being precise about the rest.

It removes the provider from the trust chain. That is most of the risk, because most breaches are somebody else's problem becoming yours.

It does not protect the device. Malware, a compromised browser or anyone with physical access to an unlocked machine can read local files. Encryption helps here only in proportion to where the key lives. A key stored next to the data, which is the usual arrangement for a tool that must decrypt without asking you for anything, protects against casual exposure in backups, disk artefacts and support screenshots. It does not protect against an attacker who can already run code as you.

Stating that plainly is more useful than claiming protection you do not have.

How to tell whether a claim is real

Three questions separate genuine local first software from a privacy setting:

1. Turn off the network and try it. Does everything still work, or does it show you a message asking you to reconnect?
2. Look for an export. Not a download of your data through their interface, but your own files in a format you can open without the app.
3. Find the data on disk. If you cannot locate it, find its format or read it with another program, the claim is decoration.

All three apply to Form ReDraft. Drafts are written to browser storage you can inspect from DevTools, encrypted with a key described openly in the documentation, and exportable as JSON.

Where the line sits

Not everything should be local. Collaborative documents belong with a server. Anything you need on a work laptop and a home desktop benefits from sync. Tools that need serious processing power need a machine with serious processing power.

The right question is narrower and more useful: for this particular piece of data, on this particular device, does a stranger need to be able to read it? For the text you typed into a form on your own machine, the answer is no, and there is no reason a server should ever be involved.

Keep it local when one person needs it. Sync it when two do. Send it to a server when neither of those is true.

FAQ

Related Articles