Construction sites are located exactly where the network is not: city outskirts, basements, the middle of a road corridor, the eighteenth floor of a concrete frame. Yet most construction software is evaluated in an office on excellent wifi, and purchased on the strength of that evaluation. The result is a field team back on paper within a month and an office keying in data every evening — precisely the situation the software was bought to end.
Key takeaways
- “Supports offline” usually means “displays cached data” — the entire distinction is whether you can write, not read.
- Exactly one sync queue. Two parallel queues produce duplicate records on flaky networks.
- Sync halts on error rather than skipping past it — skipping leaves silent holes in the record.
- The unique id is generated on the device before transmission; that is what makes retries safe.
- Personal data does not belong in the browser cache — queuing your own pending writes is not the same as caching server responses.
The problem is not a weak network, it is an intermittent one
A total absence of network is comparatively easy: the app knows it is offline and behaves accordingly. The hard case is intermittent connectivity — a signal that appears and vanishes every few seconds, or a connection that technically exists but is slow enough that the request times out.
In that state, the device reports “online”, the app sends the request, and the request genuinely reaches the server — but the response does not come back before the timeout. The app concludes the operation failed and retries. The server has now received it twice.
The real test of a field application is not “does it work offline?” but “what happens when the network drops mid-transmission?”.
Offline reads are easy; writes are the question
When a vendor says their app “works offline”, ask one question: can I create a new record while disconnected? The answer separates a marketing feature from an operational one.
| Level | What the user can do | Engineering effort |
|---|---|---|
| Cached display | See the last data loaded while online | Low |
| Full read | Browse projects, tasks and drawings entirely offline | Medium |
| Write with a queue | Create and edit records, sync later | High |
| Write with conflict resolution | All of the above, plus handling a concurrent edit by another user | Very high |
Most products sit at the first level and market themselves as if they were at the third. The field team discovers the difference on day one of real use.
How a sync queue is built
The core idea: the application never sends to the server directly. It writes the operation to a local queue, and the queue attempts delivery. That separation is what makes behaviour identical whether or not there is a network.
Generate a unique id on the device
Before the local write, a UUID is generated for the operation and sent with the request, so the server can distinguish “a new operation” from “a retry of one I already accepted”.
Write locally first
The operation is persisted to IndexedDB with its state and creation time. The user sees the result in the interface immediately — no waiting on a server response.
Transmit in creation order
The queue drains in strict chronological order. Sending an update before the record it updates has been created produces a misleading server error.
Halt on validation errors, do not skip
If the server rejects an operation on a data error, the queue stops and surfaces it. Continuing means later operations — which may depend on the rejected one — fail silently or write wrong data.
Back off and retry for network errors only
A network error deserves a retry; a validation error (400) never does — re-sending invalid data will not make it valid.
Conflicts: what if two people edit the same thing?
A site engineer updates a task’s progress at 10:00 while offline. The project manager updates the same field from the office at 11:00. The engineer regains coverage at 13:00 and their operation is transmitted. Which value survives?
There is no technically correct answer — it depends on the domain. But there are three policies, and choosing one deliberately is far better than leaving it to chance.
- Last write wins: the simplest, and acceptable for data where losing a version does no harm (a free-text note, say).
- Reject on version change: the server refuses the operation if the record changed since it was read, and the user is asked to review and retry. The right choice for financial figures and quantities.
- Field-level merge: both operations are accepted when they touch different fields. The best user experience and by far the most expensive to build.
What must never be cached on the device
Enthusiasm for offline support sometimes leads to caching everything locally. That is a security mistake, and a sharper one on a multi-tenant platform where a single handset may be used by more than one person.
- Server responses containing personal data (payroll, worker records, HR documents) do not belong in the browser cache.
- The offline fallback page must be a static, tenant-agnostic page — never a cached dashboard, or one user’s data gets served to another.
- Session tokens do not belong in storage readable by any script on the page.
- What is stored is the current user’s pending writes — not a replica of the database.
Offline-first means keeping what you have not sent yet, not keeping a copy of everything you have received.
Questions that expose the claim
Before buying any field platform, these five questions establish the real level of support in minutes:
- Can I create a new daily report and attach a photo to it in airplane mode?
- What happens if I close the app completely before coverage returns — does the operation survive?
- If the connection drops mid-transmission, does the record appear once or twice?
- If the server rejects one operation in the middle of the queue, what happens to the ones behind it?
- What is stored on the device, when is it cleared, and what happens on sign-out?
Ask for a live demonstration, not an answer in a document. Running the first three on a handset in airplane mode takes under five minutes and tells you more than a full feature-matrix comparison.
How muqawil is built
muqawil is a progressive web app built on this model: a single source of truth for pending writes, stored in IndexedDB, drained in creation order, halting on validation errors rather than skipping them.
- Daily reports, task updates and attendance check-ins are created offline and synced later.
- A unique id is generated on the device per operation, preventing duplicates on retry.
- API requests are never cached — responses can contain personal data.
- The offline fallback is a static, tenant-agnostic page.
- Runs on any Android handset with no app-store download.
Frequently asked questions
What is the difference between a PWA and a native app for offline work?
On offline capability alone the difference is small today: both store locally and sync later. The practical difference is distribution — a progressive web app installs straight from a link with no app store, which matters a great deal when your field team is on assorted handsets and you do not want to manage store updates.
How long can the app work offline?
The duration itself is effectively unlimited — the constraint is device storage and the number of pending operations. The real limit is session expiry, so the app should tell the user when it needs a connection to renew the session rather than surprising them with it.
Is data lost if a worker closes the app before syncing?
No, provided operations are stored in IndexedDB — they survive closing the app and restarting the device. Data is lost only if the user manually clears browser data or uninstalls the app.
What about photo uploads while offline?
Photos are stored locally as binary and uploaded with their operation when coverage returns. The important detail is compressing on the device before storing — 12 MB photos across a thirty-operation queue will consume device storage and make the eventual sync painfully slow on a weak connection.
Do we really need all this if our sites are inside cities?
Even inside cities, basements, lifts and the lower floors of concrete frames remain dead zones. The difference is that an offline-first app does not behave differently in those moments — no error screen and no lost work, just a sync delay the user never notices.
Test it in airplane mode
Create an account, open muqawil on your handset, switch on airplane mode, and file a daily report. Then reconnect and watch it sync.