Building for the bandwidth you actually have

There is a class of software failure that never shows up in the office where it was built. The application works on the developer’s fibre connection, passes every test, and then arrives at a branch, a site or a depot where the network drops for ninety seconds every few minutes. Forms are lost. Records are duplicated. Staff go back to paper, and the project is quietly filed under “did not work”.

The system did work. It was built for somewhere else.

Assume the connection will go, because it will

Offline tolerance is not a feature you add later; it is an assumption that shapes the architecture. The client keeps a local copy of what the user is working on. Every action is recorded as an event with a stable identifier, so it can be sent twice without being applied twice. The server accepts events out of order and reconciles them, and the user sees what has been saved locally and what has been confirmed by the server — two different states that most interfaces collapse into one.

Small, resumable, idempotent

Requests are small enough to succeed on a poor link and resumable when they do not. A large upload is broken into chunks that each carry their own checksum. A retry is safe by construction, because the server treats the same event identifier as the same event. This is where most “the record was saved three times” bugs come from, and where they are fixed.

Design the interface for the wait

The worst experience on a slow network is not slowness; it is uncertainty. A spinner with no end, a button that may or may not have done something. We show what is pending, what is confirmed and what failed and will be retried, and we let the user keep working while the queue drains behind them.

Measure on the real link

Every project of this kind has a test profile that throttles the connection to the bandwidth and drop-out pattern measured at the actual site. Features are signed off on that profile, not on the office network. It is the single change that has done the most to stop “it works here” reaching the field.

Modest hardware is a constraint, not an excuse

The same discipline applies to the machine the software runs on. A web client that is light enough for a five-year-old laptop and a mid-range phone will still be light on a new one. The reverse is not true, and the businesses we work with rarely get to choose their hardware.

Built this way, software behaves the same at the head office and at the furthest site — which is, in the end, the only definition of working that matters.