Local-first starts with the work, not the network.

You open an application to add a thought. Before you can write it, the application needs to check an account, contact a service, and decide whether the connection is good enough.

For some tasks, a live service is essential. For a personal note, it is worth asking why the network gets the first turn.

Local-first is an interesting answer to that question. Not because every application should avoid the cloud, but because the work should have a place to exist close to the person making it.

More than an offline badge

Ink & Switch’s original local-first software essay describes a model that combines local ownership with collaboration and cross-device access. The local copy is primary, rather than just a temporary copy waiting for a server’s approval. Servers can still participate in synchronization.

That is a more useful starting point than “this app works without Wi-Fi.” It asks what authority the local copy has and what remains possible when the service is unavailable.

For a hypothetical notebook, I would want to separate three statements: your edit is saved on this device, it has reached another device, and a recoverable backup exists. Those statements should not share one vague checkmark.

Local storage is not the same as a backup

Keeping information on a device does not protect it from a lost laptop or an accidental deletion. Synchronization and backup also answer different questions: distributing the current state is not necessarily preserving a previous one.

Browser-based storage needs particular care. MDN’s documentation on storage quotas and eviction explains that browser storage can be best-effort and subject to removal, and that persistence behavior varies. A local browser database is not a promise that the data will remain forever.

The product needs to explain its actual storage behavior. Offer an understandable way to make a separate copy, and test restoration rather than stopping at a successful download.

This is where a useful export becomes part of the everyday experience, not an obscure setting for people who plan to leave.

Decide how devices disagree

Take a notebook edited on a phone and a laptop while both are offline. Someone changes the title on one and the body on the other. Later, the devices reconnect.

What outcome would the person expect? What happens when both edits affect the same sentence? Does the application preserve alternatives, combine them, or ask for a choice?

Those are product questions as well as implementation questions. The interface should make uncertainty visible and preserve work where practical. A hidden conflict policy is still a policy, even when nobody has written a sentence explaining it.

Choose the approach for the task

Local-first is not a universal requirement. A shared service with central records may need a different architecture. Even a local-first product can use online services for selected capabilities, provided the boundaries are clear.

For WunderSpark, the attraction is a design question rather than a label to place on every product: can the useful part stay available without asking a remote system for permission each time?

A good answer should be visible in the ordinary experience. Open the work. Make the change. Understand where it is saved. Know how to keep a copy.

The network can help. It does not always need to be in charge.