Offline first: why mining software needs to work without connectivity

The connectivity reality

Software vendors love to demo their products on fast office wifi. Everything loads instantly, syncs perfectly, and looks beautiful. Then you try to use it at a mine site 400 kilometres from the nearest regional centre, where the internet comes through a satellite link shared by 200 people, and the experience falls apart.

This is the reality of connectivity in Australian mining. Many surface operations rely on satellite or microwave links with limited bandwidth and variable latency. Underground operations are worse. WiFi coverage below ground is patchy at best, often limited to main declines and a few development headings. Large sections of an underground mine have no coverage at all. A technician working on a loader at the face might be completely disconnected for hours at a time.

Why cloud only fails

Most modern software is built with a cloud first architecture. Every action requires a round trip to a server. Open a fault record: server request. Add a note: server request. Upload a photo: server request. View a diagnostic procedure: server request. Each of these relies on a stable connection. When the connection is slow, the app is slow. When the connection drops, the app is useless.

This creates a practical problem that no amount of good UX design can fix. If a tech can't log a diagnostic step because they don't have signal, they either wait until they're back in range, try to remember what they did later, or stop using the system altogether. All three outcomes defeat the purpose of having a digital fault management system. The tool is supposed to make work easier, not add a connectivity dependency to every action.

What offline first actually means

Offline first is not the same as “works offline sometimes.” It's a fundamentally different architecture. In an offline first application, the device is the primary data store. Everything the user does, every note, every photo, every status update, is written to the local device first. The app works at full speed regardless of connectivity because it doesn't need the server to function.

When connectivity becomes available, the app synchronises with the server in the background. New data is pushed up, updates from other users are pulled down, and any conflicts are resolved automatically. The user doesn't need to think about whether they're online or offline. The experience is the same either way.

Real world scenarios

Consider a heavy diesel fitter working on an underground loader at a development heading. They've identified a fault, taken photos of the damaged component, and need to log their findings and request parts. With a cloud only app, they'd need to walk back to an area with WiFi coverage, which might be a 15 minute drive in a light vehicle, just to update a record. In practice, they won't do that. They'll scribble something on a piece of paper or try to remember the details later.

With an offline first app, they log everything on the spot. Photos, notes, diagnostic steps, parts requests. All captured in real time, stored on the device, and synced automatically when they drive back through an area with coverage. The information is complete and accurate because it was recorded at the point of work, not reconstructed from memory hours later.

Or consider a remote surface operation where the satellite link goes down for four hours due to weather. On a cloud only system, the entire maintenance team loses access to fault records, work orders, and documentation for that period. Work continues, but nothing gets recorded. Four hours of maintenance activity becomes a gap in the record. With offline first, nobody notices the outage. The app keeps working. Records keep being created. When the link comes back, everything syncs.

Sync when available

The technical challenge of offline first is synchronisation. When multiple people edit data while disconnected, their changes need to be merged when they reconnect. This is a well understood problem in distributed systems, but it requires careful engineering. Timestamps, conflict resolution rules, and data versioning need to work reliably across devices, time zones, and connectivity patterns.

The sync also needs to be bandwidth efficient. When a tech connects to a slow satellite link, the app shouldn't try to upload 50 full resolution photos at once and saturate the connection. Smart sync means prioritising critical data, compressing where possible, and being respectful of shared bandwidth. This is especially important on sites where the internet connection is shared between operational systems, communications, and business applications.

Built for where the work happens

Mining maintenance doesn't happen in offices with fibre internet. It happens underground, in remote workshops, at the face, on the pit floor, and in conditions that most software engineers never encounter. Building software for mining means accepting that connectivity is not guaranteed and designing accordingly. Offline first isn't a nice to have feature. It's the baseline requirement for any tool that claims to be built for mining. If your maintenance software stops working when the WiFi drops, it wasn't built for your environment. It was built for a demo room.