A site loses signal exactly where people need the system
The first time you take a piece of software onto a live site, you learn something no requirements document will tell you. There is no signal in the basement. There is no signal inside the steel frame. There is patchy signal in the compound and good signal in the car park.
That is why everybody stands in the car park to do their paperwork at four o’clock. It is also why the paperwork is done from memory. The software may look fine in the office, but the site changes the terms of the work.
Almost every failed construction software rollout we have been asked to look at failed on this point. The failure was not about features. It came from an assumption, made silently and early, that the device would be able to reach a server when the person needed it to.
Offline support has to shape the build from week one
There is a version of offline support that gets added late. It caches the last few screens, meaning it saves them on the device, queues a couple of actions, and shows a warning bar. That is better than nothing, but it does not survive contact with a site.
The moment the person needs to do something the cache did not anticipate, they are stuck. They are holding a device that is telling them to try again later, while the work is happening in front of them.
Offline first means the device can do the work before it talks to the server. The device holds the truth for the work in front of it. Everything is written locally, immediately, and the network becomes a background concern that reconciles when it can.
The interface never blocks on a request, so it does not stop the user while waiting for a server reply. There is no spinner that might mean anything. The person finishes the task and walks on.
That is an architectural decision, made in week one, and it constrains everything afterwards. You cannot bolt it on, because the entire data flow runs the other way.
Contradictory records need a designed answer
Once two people can both record something while disconnected, they will eventually record contradictory things. A naive system takes the last write and destroys one of them silently. On a site, that means somebody’s inspection disappeared, and nobody finds out until a dispute.
Conflict has to be a designed outcome rather than an accident. Most site records are append-only by nature, meaning new entries are added without changing the old ones. That helps enormously because many site records accumulate rather than replace each other.
These records usually accumulate:
- An observation.
- A photograph.
- A delivery note.
- A sign-off.
The things that can be changed are few. For those, we keep both versions, mark the record as contested, and put it in front of a human. It is slightly more work, and it is the difference between a system people trust and one they audit against paper.
Site records have to hold up as evidence
Variations, approvals and inspections are the evidence in a dispute that may happen three years from now, long after everyone involved has moved on. If they can be quietly edited, they are worth very little when it matters.
We append rather than overwrite. A correction becomes a new entry with an author, a timestamp and a reason, and the original stays visible. People occasionally push back on this, usually because a mistake is embarrassing and they would rather it vanished.
The answer is that a record which can be made to vanish is a record that proves nothing, including the things you want it to prove.
Offline records need more than one time
If entries are captured offline and synced hours later, the recorded time matters. You have the time it happened, taken from a device clock that may be wrong. You also have the time the server received it, which is definitely wrong for the work itself.
The answer is both, always, and never one. Every entry carries the device time, the server receipt time, and the offset between them measured at the last successful sync.
That triple lets you reconstruct what actually happened even when a device clock has drifted or somebody has changed it. It costs three columns and it resolves arguments that would otherwise be unresolvable.
The system has to work with the tools people already use
Every contractor already has a scheduling tool. Every client already has an accounting system. Every consultant already has a document platform they will not abandon.
A new system that requires everyone to move is not going to be adopted, however good it is. Adoption is not a technical decision made by the person you sold to.
So the question we ask first is about exchange of data between systems. We need to know which existing systems it must exchange data with, in which direction, and who owns the mapping when a field means slightly different things on each side.
That last part is where the effort really goes, and it is almost never in the estimate somebody else gave.
The interface has to work in gloves
The interface constraints on a site are unusual, and they are not negotiable. The person using the system may be wearing gloves, standing in sun, holding something else, and reading from a device in a case on a lanyard.
The constraints are simple:
- Large targets, because the person is wearing gloves.
- High contrast, because the sun is out and the screen is not bright enough.
- Few taps, because they are holding something in the other hand.
- Readable at arm’s length, because the device is in a case on a lanyard.
These sound like accessibility guidelines, and they are. The motivation is adoption. A form that takes eleven taps in an office takes four minutes on a scaffold. The person will do it later, from memory, in the car park.
Every additional interaction is a small tax on data quality, paid at the worst possible moment.
Photographs are often the record itself
On most sites the actual evidence is a photograph, and most systems treat photographs as attachments. That has the relationship backwards. A photograph with a location, a timestamp, an author, and a link to the item it documents is the record. The text is annotation.
That means the capture path has to be fast and the storage path has to be resilient. A site worker takes forty photographs on a walk-round, on a device with intermittent signal and finite storage.
The system needs to hold all of them locally, upload opportunistically when the connection allows, compress sensibly without destroying detail that might matter in a dispute, and never lose one because the app was closed.
Sync needs the same care as a payment
The word sync makes it sound like a background convenience. Sync is the process that moves work between the device and the server when a connection exists. It often gets built as a loop that posts anything unsent and marks it done.
That works until the first time a response is lost in flight. At that point, the device does not know whether the server received the entry or not. Both available choices are wrong:
- Send it again and you risk a duplicate inspection in the evidence file.
- Do not send it and you risk losing it entirely.
The way out is the same mechanism that makes payments safe. Every entry gets an identifier generated on the device at the moment of capture, instead of being assigned by the server on receipt.
The server treats that identifier as the key. A repeat submission returns the original outcome rather than creating a second record. The device can then retry as often as it likes, on a flaky connection, from a background task, after a crash, without any possibility of duplication.
It also means two devices that somehow both hold the same queued entry converge rather than conflict.
The order of offline work also matters
The second half is ordering. Entries captured over four disconnected hours have a sequence that matters. A defect raised, then closed, then reopened is a different story from one raised and reopened and closed.
We carry a per-device sequence number alongside the identifier, so the server can reconstruct the order the person experienced. That order stays independent of the order the packets happened to arrive in.
Battery and storage have to last the shift
A site device is not plugged in. It is in a pocket or a case for a full shift, and it is running a screen at full brightness because the alternative is not being able to read it outdoors.
Anything the software does continuously competes directly with the ability to still be working at four o’clock.
That rules out a few habits that are harmless elsewhere:
- Polling a server every thirty seconds to check for updates is a meaningful drain across eight hours and buys almost nothing, because site records are not time critical to the minute.
- Continuous high accuracy location tracking is worse, and it is also a privacy question that somebody will eventually and reasonably ask about.
- Uploading full resolution photographs the instant they are taken, over a marginal connection, will empty a battery faster than anything else the product does.
So we batch. Sync opportunistically when the connection is good, upload photographs at a sensible resolution with the original retained on device until confirmed, and let location be captured at the moment of capture rather than tracked continuously.
Storage gets the same treatment. A device holding several thousand queued photographs needs a policy for what happens when it fills, and the policy must never be to silently discard the oldest.
We measure whether the system works on the real site
On these projects, we measure the things that show whether the system works where the work happens:
- Entries captured while disconnected, as a proportion of all entries. It is usually far higher than the client expects, often more than half.
- Longest observed offline period that ended in a successful sync.
- Entries lost. Target zero, measured explicitly rather than assumed.
- Median taps to complete the three most common tasks.
- Time from capture to visibility for someone in the office.
The first of those is the one that changes the conversation with a client. When you can show that fifty eight percent of everything recorded last month was recorded with no connection, the argument about whether offline support was worth the extra fortnight ends immediately.
A narrower tool worked because it matched the site
A contractor came to us after a failed rollout of an off-the-shelf inspection product. Adoption was around fifteen percent after four months, and the site teams had reverted to a paper pad photographed at the end of the day.
The product was not bad. It required a connection to open a checklist, which meant that on most of the sites in question you could not start a task where the task was.
The workaround was to open everything in the compound in the morning. Nobody remembered to do that, so the tool was useless exactly when it was needed.
We replaced it with something narrower that did less:
- Checklists cached in full on sync.
- Capture entirely local.
- Photographs queued.
- Reconciliation on reconnect.
- Four taps to log a defect.
Adoption at four months was eighty one percent. The client valued the dispute file for a variation assembling itself more than the adoption number, because the evidence had been captured at the moment it existed rather than reconstructed a week later.
The connected version only looks cheaper at the start
Building this way costs more in the first phase. Local storage, sync logic, conflict handling and a genuinely offline-capable interface are perhaps a third more work than the connected version.
The connected version demos identically in a meeting room with good wifi. That is why the cheaper choice can look safe before anyone takes it onto a live site.
We say so in the proposal, and we show the adoption numbers from the projects where it was skipped. The cheaper build is only cheaper until it is not used, at which point its cost is the entire budget plus the credibility of whoever championed it.
More on how we approach this sector on our construction and real estate page, and on the delivery method behind it in how we work.
