Blackspots, Basements and Stone Walls: Engineering Field Software That Keeps Working

Field software has a habit of being designed in offices with reliable wi-fi and tested on a commute. That is not where it is used. An engineer servicing a plant room beneath a Leeds hotel, a surveyor recording defects in a listed barn in North Yorkshire or a community care worker updating notes in a Cornish village may all be working with no usable connection. The commercial risk is not simply a delayed update. It is a missed visit, a duplicated job, an inaccurate record or a professional who no longer trusts the system.

Offline-first is often presented as a technical feature. In practice it is an operating model. The application must assume that connectivity is optional, intermittent and sometimes misleading. A phone can show two bars and still fail to send a request. A tablet can connect to a captive portal in a café and appear online while no application traffic passes. Good field software is built around those realities rather than treating them as edge cases.

Start with the operational reality

Before choosing a database or a sync library, map the work. Which records must be created or changed on site? Which reference data must be available before arrival? How long can a device reasonably go without synchronisation? What happens if two people edit the same job? What evidence, such as photographs or signatures, must be captured and retained? These questions determine the architecture more than any framework choice.

For most UK field teams, the minimum viable position is a local store on the device that can survive an application restart, a flat battery and a lost signal. That usually means a structured database rather than a cache of API responses. Writes should be committed locally first and placed in an outbox for later transmission. Each local record needs a client-generated identifier so that a job created underground can be reconciled with the server when the device resurfaces. Photographs and documents need a clear retention and upload policy, because storage on a mobile device is finite and field evidence can be large.

Store locally, synchronise deliberately

Local-first storage is not the same as storing everything forever. A pragmatic design separates reference data, operational records and transient artefacts. Reference data, such as site addresses, asset lists and safety documents, can be pre-fetched and versioned. Operational records need durable local writes and an explicit sync queue. Transient artefacts, such as a temporary photograph, need a defined lifecycle: capture, compress, queue, upload, verify and then remove from the device when policy allows.

Synchronisation should be deliberate and observable. The application should know what is pending, what has been acknowledged and what has failed. Requests should be idempotent so that a retry after a timeout does not create duplicate job notes. The server should be authoritative for shared state, but it should not pretend that a device is online when it is not. Useful telemetry includes queue depth, age of oldest pending item, sync failure reasons and the time of the last successful exchange. These are operational metrics, not merely engineering curiosities.

Conflicts need a policy, not an apology

Sync conflicts are inevitable when people work independently. Last-write-wins is simple, but it is rarely honest for field records. If a care worker updates a visit note while a supervisor updates the care plan, overwriting one with the other loses context. A better approach is to define conflict policy by data type. Some fields can be merged at field level. Some records should be append-only, with corrections represented as new entries. Some changes should be routed to a review queue where a human can compare versions.

The interface should make conflicts understandable. Showing a user a raw JSON diff is not acceptable. Showing 'your change was not saved' is also insufficient. The system should explain which record changed, what the other version contains and what action is required. An audit trail matters, particularly where records support statutory, contractual or professional obligations. The aim is not to eliminate every conflict but to ensure that no change disappears silently.

Design the disconnected interface honestly

When the connection drops, the software should not become a different product. Users should be able to continue the tasks that matter, with clear indicators of what is local, what is queued and what is confirmed. A persistent but unobtrusive status area is usually better than a modal dialog that blocks work. The status should distinguish between 'offline', 'connecting', 'syncing' and 'sync failed', because those states imply different user actions.

Avoid false reassurance. A green tick that means 'saved on this device' should not be presented as 'received by head office'. If a signature or photograph is pending upload, say so. If a job cannot be started because essential reference data has not been downloaded, explain that before the user travels. Provide a manual retry and a clear route to support. In rural areas, the useful question is often not 'are you online?' but 'what can I safely do now?' The interface should answer that question directly.

Test the conditions, not the demo

Testing offline behaviour by trying the application on a train is not a QA plan. It is an anecdote. A proper test approach uses network emulation to simulate high latency, packet loss, captive portals and complete loss of connectivity. It includes cold starts with no signal, application termination during a sync, device storage exhaustion and low battery conditions. It should cover the devices the field team actually uses, including older Android handsets and tablets in protective cases.

A field pilot is still valuable, but it should be structured. Recruit users who work in basements, rural locations and older buildings. Ask them to record what the application told them and what they expected. Compare the local queue with the server record after the visit. Test the support path as well as the software: can a team leader see which devices have not synced, and can they resolve it without a site visit? These checks turn offline capability from a claim into evidence.

Measure the cost of being offline

Offline-first design has a cost. It adds complexity to data modelling, testing and support. That cost should be justified by operational benefit: fewer repeat visits, faster completion, more reliable records and less administrative reconciliation. Track those outcomes. If a team spends less time re-entering notes or chasing missing photographs, the investment is doing its job. If the sync queue becomes a hidden backlog that nobody owns, the design has failed regardless of how elegant the local database is.

For UK field operations, the practical baseline is modest but demanding: durable local writes, an observable outbox, explicit conflict rules, an honest interface and a test regime that reflects real conditions. The technology can be ordinary. The discipline cannot.