Software should keep working when the network does not

A surprising amount of modern software stops being software when the connection disappears. The interface remains on screen, but every meaningful action becomes a request sent somewhere else. A weak signal turns an ordinary task into a queue of spinners, retries and uncertainty.

That arrangement is sometimes necessary. Collaboration needs a shared place. Large searches may need machines beyond the one on your desk. But the network has become the default answer even when the work starts locally, ends locally and concerns only one person.

Offline is an ownership test

“Works offline” is usually presented as a convenience for trains and flights. It is more useful to see it as a test of the product’s centre of gravity.

If the core task continues without a server, the device holds a real copy of the work and enough capability to act on it. If the core task stops, the interface is often only a remote control. That distinction affects much more than travel. It determines what happens during an outage, after a pricing change, when an account is locked or when a service is eventually switched off.

Local capability gives the user a stronger default position. Their work is present. The tool can respond. The network can add reach without being the source of permission for every action.

Local-first is not local-only

There is no virtue in refusing the cloud where it is the right part. Shared documents, team state and public publishing all need coordination. The useful question is smaller: which parts genuinely require a remote computer?

A local-first design keeps essential state and essential operations on the device, then uses the network deliberately. Synchronisation becomes a feature rather than the foundation. Collaboration becomes an extension rather than a prerequisite. The product can explain what leaves the machine because the answer is no longer “everything.”

This separation also improves failure modes. A delayed sync is understandable. A text editor that cannot accept text because a server is unavailable is not.

Reliability is part of the interface

We tend to discuss reliability as an operational concern: uptime percentages, incident response and redundant infrastructure. Users experience it more directly. Reliability is whether the tool does what it appeared ready to do.

Device-native software has failures too. Disks fill up. Models may not load. Permissions can be denied. The difference is that many of those failures are visible, bounded and under the user’s control. They do not arrive silently from a dependency several companies away.

The goal is not to pretend the network does not exist. It is to put it back in proportion. Software should be able to use the internet without becoming unusable in its absence. The device in front of you is already a capable computer. We should let it act like one.