"It should work offline" is one of those requirements that sounds like a checkbox and behaves like an architecture. Agreeing to it in month one costs a conversation. Adding it in month nine costs a rewrite.

So it is worth being precise about what it means, because there are three quite different things people mean by it.

Three kinds of offline

Read-only offline. The app caches what it last saw so a user can look things up on a train. Useful, cheap, and not what most operational businesses need.

Queue-and-send. The user can perform actions with no connection; those actions are stored locally and sent when the network returns. This is what a business usually means, and it is a serious piece of engineering.

True local-first with merge. Several people edit the same records offline and the system reconciles conflicting versions. This is a research-grade problem in the general case. Avoid it unless the business genuinely requires it, and be suspicious of anyone who agrees to it casually.

Most real projects need the middle one. In the operations platform we are building now, that means customers, appointments, questionnaires, captured images and orders are all written to local tables backed by an operation queue, then replayed to the server when the connection comes back.

What queue-and-send actually costs

Every entity gets a local shadow. Not just the data, but the metadata: what has been sent, what has not, what failed and why.

Identity gets complicated. A record created offline needs an identity before the server has ever seen it, and that identity has to survive the round trip so that everything created afterwards still points at the right thing.

Order matters. An appointment created offline and an order created against it thirty seconds later must reach the server in that sequence, or the second one refers to something that does not exist yet.

Failure needs a face. This is the one people leave out, and it is the one that matters most.

A silent sync is worse than no sync

If synchronisation quietly drops an operation, nobody finds out at the time. They find out later, when an item is made from measurements that were never uploaded, or when a customer's record is missing the appointment that explains the order.

That is strictly worse than the connection simply failing, because a visible failure gets handled by a human immediately and an invisible one gets handled by nobody.

So the queue needs a visible status and a way for an ordinary user — not a developer with database access — to see what has not gone through and to retry it. It is unglamorous, it never appears in a feature list, and it is the difference between offline support that people trust and offline support that people work around.

How to tell if you need it

Ask where the work physically happens, and what the person does if the connection drops at that exact moment.

If the honest answer is "waits a minute and tries again", you do not need offline-first, and you should not pay for it. If the answer is "the customer is standing right there", you do — because the alternative is staff keeping a paper notebook and typing it up later, which is the failure mode the software was bought to eliminate.

Deciding this early is worth more than deciding it well. Retrofitting a queue into a system that assumed a live connection touches every screen, every write and every identifier. It is the most expensive requirement to remember late that we know of, which is why we ask about it in the first conversation.