How to test a "works offline" claim in ten minutes
Every vendor says the app works offline, and the word means four different things. A cheap phone in flight mode settles it faster than any meeting.
Ask any vendor whether the app works offline and the answer is yes. Nobody is lying. The word covers four different behaviours, and only two of them are what a site in a basement, a cellar or a shed behind the batching plant actually needs.
The good news is that you can tell them apart on a phone, in about ten minutes, in front of the person selling it to you. Of everything on the list when choosing construction software, this is among the few claims a buyer can check without trusting anyone.
The four things "offline" turns out to mean#
- It shows what you already loaded. A cache. Read-only. Open the app in a dead spot and this morning's list is still on the screen. Genuinely useful, and often the whole of what is being claimed.
- It lets you type, and then loses it. The form accepts input, the save spins or fails quietly, and a refresh or a force-close takes the entry with it. This is the common one, and it is worse than a plain refusal, because the storekeeper walks away believing the entry was made.
- It queues the entry and sends it later. The record is written to the phone, held, and pushed when signal returns. This is what most people mean when they say offline, and what a competent implementation does.
- It holds a working copy and reconciles. The device carries real data, can be worked on all day, and merges back afterwards with rules for what happens when two copies disagree. Rare, expensive, and only worth it for some kinds of work.
Ask which one it is. Then test it, because the answer given in a meeting and the behaviour of a phone in a lift shaft are different things.
The ten-minute test#
Use a real phone, not the vendor's laptop with the wifi switched off. Preferably a cheap phone of the kind your site actually carries. It is the most valuable ten minutes available in a demo, and how to run a software demo is largely an argument for spending time this way.
- Flight mode first, then open the app. This order matters more than everything else here. Most apps survive losing signal after they have loaded. Far fewer survive being started cold with no network, and cold is the real case: a phone that has been in a pocket since morning was shut down by the operating system hours ago.
- Open a record you have not looked at today. Last week's material issue, another site's list. This separates a real local copy from a cache of whatever happened to be on screen.
- Create a record with a photograph. Photographs are where offline claims break. An image is large, and the queue that handles a line of text cheerfully is usually not the same queue.
- Force-close the app. Swipe it away properly, do not just go to the home screen.
- Reopen it, still offline. Is the entry there. Does the screen say what state it is in, or does it look identical to a saved record.
- Come back online and watch. How long before it goes. Whether anybody is told. Whether the record ends up carrying the right time.
What to ask once you know what it does#
What happens if two people edited the same record offline? Uncommon on attendance, routine on a measurement sheet or a snag list. The system can take the last writer, keep the first, or hold both and ask a person. Any of the three can be defended. Not knowing cannot.
Whose clock is on the record? The phone's or the server's. These mean different things. A server timestamp records when the data arrived, which may be hours after the man stood at the gate. A phone timestamp records the event but trusts a device that somebody is holding.
What happens when the phone's clock is wrong? More common than people expect: a factory reset, a dead battery, a handset that has not seen a network to sync from in weeks. Ask whether the system notices the skew and what it does. An entry dated next month is easy to spot. One dated slightly early is not, and it will sit in the record looking perfectly ordinary.
How large can the queue get? Ask for the limit and what happens at it. Does the oldest entry fall off, does the app refuse new ones, or does it grow until the phone complains. A supervisor through a shutdown with no signal is not a hypothetical.
What does the user see when a queued item fails to send? Not whether it retries — everything retries. What the person sees when retrying stops working: a rejection from the server, a login that expired while they were offline, a record somebody else deleted in the meantime. If the answer is a silent drop, the system will lose entries and nobody will know which ones.
Offline changes what the record means#
This is the part that outlives the buying decision.
A record made offline was created by a device nobody was watching, at a time nobody can independently verify, and checked against rules the device could not run. Some checks simply cannot happen on a phone with no network. Is this material still in stock. Is this man still on the roll. Has this order already been received against.
So the software has two options and both cost something. Let the entry through and validate it later, which means some entries get rejected after the fact and somebody has to be shown them. Or refuse, in which case the app does not work offline for exactly the cases that matter.
Which of those it chose, and where the rejected entries surface, is the real question underneath the demo. It is worked through in offline-first as a data decision. Attendance is the sharpest version of it, because the record is about a person and money follows it a fortnight later, and attendance on a site with no signal covers the duplicate punch and the clock in more detail.
The two rules we hold ourselves to#
A queued record obeys the same rules as a live one. A punch made on a phone with no signal goes through exactly the same validation, when it finally arrives, as one made in the office on a browser. Not a lenient path for the offline case — the same path. The moment a rule has two implementations, the offline one drifts, and it drifts quietly, because nobody is watching the device that produced it.
What a phone volunteers is not evidence. Our app can sample location in the background, and not one of those samples counts toward whether somebody was present, or which site they worked at. Presence is a deliberate act by a person. A location fix is a fact about a handset, and the two are not interchangeable however convenient it would be.
Ask a vendor both questions in those words. The first tells you whether the offline path is real. The second tells you what they think a record is.
The short version#
Offline means four things: it caches, it loses your typing, it queues, or it reconciles. Ask which, then take a cheap phone, switch on flight mode before opening the app, open something you have not viewed today, make a record with a photograph, force-close it, reopen it, and come back online.
Then ask about conflicts, clocks, queue limits and failed sends. A record made offline is a weaker claim about the world than one made online. The question is not whether it arrives. It is what it means when it does.