Digitising a site with no connectivity: what works offline and what does not
Intermittent connectivity is the most underestimated constraint in site digitisation. A system that works well in the office and fails twice in the field loses the user's trust permanently: after the second lost entry, the site engineer goes back to the notebook and does not come back.
And it is not a problem exclusive to remote sites. The basement of a building in the middle of a city can have worse signal than a rural road.
The four scenarios
Not all poor connectivity is the same, and the technical answer depends on which one you have.
| Scenario | Typical situation | What it demands |
|---|---|---|
| No coverage | Rural area, tunnel, basement | Fully local capture with later synchronisation |
| Intermittent coverage | Peri-urban site, building in structure | Automatic retry queue |
| Slow coverage | Saturated network, degraded 2G or 3G | Light content, deferred photo upload |
| Good coverage | Consolidated urban site | Nothing special |
The second scenario is the most common and the one that causes the most trouble, because the system “appears” to have signal. The app tries, fails partially, and the user does not know whether the entry was saved. That uncertainty is worse than the total absence of signal.
What works offline
Text and voice capture. It needs no network at the time. The entry is stored locally and sent later. It is the easiest thing to solve and the most important.
Photo capture. The same, with one consideration about size: if two hundred photos pile up unsent, the later synchronisation can be heavy. Better to compress locally and upload in batches.
Consulting already downloaded information. The item catalogue, the budget, the programme. If they were downloaded while there was signal, they can be consulted without it.
Local calculations. Productivity rates, running totals, progress for the day. If the logic sits on the device, it needs no server.
What does not work offline
Speech transcription by a large model. Good-quality speech recognition models run on servers. The voice note can be recorded without signal, but the transcription happens when there is a network.
This is not a problem if the design accounts for it: the site engineer records, the system queues, and when there is signal it transcribes and returns the confirmation. The site engineer does not wait.
Any analysis against data from other projects. Comparisons between projects, company-wide roll-ups, management dashboards. All of that lives on the server side.
Synchronisation between users. If two people record on the same project with no signal, their data are invisible to each other until both synchronise.
Agreement and signature from the counterparty. It requires both parties to be connected. A signature can be requested without signal, but it completes when there is one.
Why WhatsApp solves a good part of the problem
It is worth pointing out because it tends to be overlooked: WhatsApp already solved the retry queue problem, and solved it well.
When there is no signal, the message sits with a clock mark and sends itself when the network appears. The user does not have to do anything, does not have to remember, and does not have to wonder whether it was saved. It is behaviour people already know and already trust.
Any site capture system that leans on that channel inherits that robustness without building it.
The problem the queue does not solve
And here is the point almost nobody considers: the queue solves delivery, not the date.
A message sent on Tuesday at four in the afternoon, with no signal, may reach the server on Wednesday at seven in the morning. If the system attributes the record by arrival time, you have just produced a logbook with the wrong date.
And a logbook with wrong dates is worse than no logbook, because it destroys the credibility of the whole record. If a single entry has an inconsistent date, any counterparty will question the rest.
The design answer is to keep two clocks and never mix them:
- Declared date: the device time when the user captured, or the one the user states explicitly
- Received date: the server time, authoritative and independent
Both are stored, both are shown, and when they differ, the difference is explained. A trivial mechanism to declare retroactively is also needed: “this was from yesterday”, recorded as a statement by the user and not as data from the system.
Evaluation questions
Five questions to ask any vendor before you buy:
- What exactly happens if I record with no signal? Ask them to prove it by putting the phone in aeroplane mode during the demo. It is the most revealing test and almost nobody asks for it.
- How does the user know the entry was saved? There has to be an unambiguous visual signal.
- What happens if the message arrives the next day? This is where you tell apart who has thought about the problem.
- How much space does the app take and how much data does it use? Many site workers are on limited prepaid plans. A system that eats the user’s plan will not be used.
- What happens if the phone is lost or broken? Are the unsynchronised entries lost?
What is worth solving before digitising
Two practical things that save a lot of pain:
Map the real coverage of the site. Not the operator’s theoretical map: walk the fronts and note where there is signal. There is almost always a point —the site office, the entrance, a high slab— that does have it. That point becomes the synchronisation place.
Provide connectivity at one point at least. A router with a mobile connection in the site office costs little and solves most cases. It is cheaper than any software engineering for operating without a network.
Frequently asked questions
- Is it worth digitising a site with no coverage at all?
- Yes, if capture is local and synchronisation deferred. What does not work is a system that demands a permanent connection. On sites with no coverage, a single synchronisation point at the end of the day is usually enough.
- What happens if two people record the same thing with no signal?
- A data conflict is created that has to be resolved on synchronisation. Serious systems detect it and show both versions. Those that do not consider it overwrite with whichever arrives last and lose information silently, which is the worst possible behaviour.
- Does a web app do the job or do you need a native one?
- A well-built progressive web app works offline for most cases and avoids the installation problem. Native has the advantage when deep access to the camera or storage is needed, for example to preserve the original metadata of photos.
- Does offline capture drain the battery?
- Capture does not; synchronisation does, above all when it hunts for a network aggressively. A well-made system synchronises when it detects good signal, not by trying every thirty seconds.
- How do I handle the date if the phone clock is wrong?
- It is a real case, and that is why the system must store both dates. When the difference between the device clock and the server clock is implausible, it is better to flag it for review than to accept it silently.
Chilean, designing for Latin America. Field research surfaces what actually matters to clients, and that becomes products non-technical people adopt on their own — legal, education, accounting — and that show up in productivity from week one.
See all their articles →
