'Works offline' until it doesn't: the field-data reality

If a field data collection app advertises offline support but hangs the moment there is no signal, takes tens of minutes to open, or clears a half-finished form, it is not offline-first. It is online-first with a cache bolted on. Real offline-first is an architecture — a durable local store, explicit conflict resolution, and resumable sync — not a checkbox on a feature grid. The public reviews below show what ships when the checkbox arrives without the architecture.

What do the Repsly reviews actually say?

Two independent public review corpora carry the same complaint in different words: the offline story holds until the network is genuinely gone. Across Capterra and Google Play — the two places field reps tend to vent — the pattern (as of early 2026) is the same. One Capterra reviewer describes an app that is meant to keep working with no connection and instead stalls:

works offline or with no signal but it does not, it hangs

A Google Play reviewer puts a number on the cold start, reporting that the app takes at least 30 minutes to open and become usable. Thirty minutes is not a slow splash screen; it is the length of a short store visit spent staring at a spinner. And once the app is open the data is not safe either. Reviewers report forms that randomly clear, wiping close to 100% of an in-progress visit:

forms will randomly clear causing them to lose all work

'All work' is the operative phrase. A rep who loses a form loses the whole visit: the audit answers, the order lines, the photos, the signature. There is no partial draft to fall back on, and no way to reconstruct what was on screen.

Why does an 'offline' app hang the moment there is no signal?

The diagnostic tell is that the failure tracks no signal, not weak signal. A genuinely offline-first client should not care whether the radio is on; it reads and writes locally and reconciles in the background. An app that freezes at zero bars is almost certainly making a synchronous network call somewhere on the hot path — a token refresh, a config or catalog fetch, a 'sync now' that blocks the UI thread on a socket that will never connect. With signal, that call is merely slow. With no signal, it waits for a timeout, and timeouts stack: 30 seconds here, 60 there, several requests deep, and the screen is frozen for the duration.

The 30-minute open is the same pathology at scale. Instead of trusting a warm on-device database, the app appears to replay or re-fetch a territory's worth of history on launch, so a large route with months of visits turns startup into a full sync. Resumability is the piece most often missing: if a sync that dies at 80% restarts from zero, every flaky lift ride or basement stockroom becomes a fresh half-hour tax rather than a few seconds of catch-up.

Where does the field data actually die?

Two quieter limits compound the sync problems, and they are more corrosive because they damage data rather than block it. Reviewers note that a wrong-store check-in cannot be reassigned, and that submitted data cannot be self-edited by the rep who entered it. Both point to one design decision: the server is treated as an immutable source of truth, and the device has no first-class amend path. A rep who checks in at the wrong address, or fat-fingers a case count, cannot correct it from where the mistake happened. The record hardens the instant it syncs, and the cleanup migrates to someone in head office with database access.

This is how data quality dies in the field — not in a dramatic outage but one uncorrectable record at a time. We have made the same argument about rigid platforms where the fix for a small mistake lives days and several approvals away from where it was made, in our note on the 29-day sandbox and other deployment stories. The table below maps each documented symptom to the architectural gap it exposes.

What does real offline-first actually require?

Offline-first is three hard problems, and shipping one of them without the others is worse than shipping none, because it advertises a promise the app cannot keep.

• A local store as the source of truth. Reads and writes hit a durable on-device database first, always, with the network as a background reconciler. The UI never blocks on a socket, so airplane mode and full signal look identical to the user.
• Explicit conflict resolution. When the same record is edited on two devices offline, the system needs a stated rule — last-write-wins, per-field merge, CRDTs, or a human review queue. 'Whatever synced last' is not a strategy; it is a silent data-loss policy with good PR.
• Resumable, idempotent sync. Transfers are chunked, checkpointed, and safe to retry, so a killed app resumes instead of restarting and a double-send never creates a duplicate order.

Miss any one and the failure is exactly what the reviews describe. No local source of truth, and the app hangs at zero bars. No durable write path, and forms clear. No resumable sync, and opens stretch to half an hour. No conflict model, and wrong-store check-ins pile up with no one able to fix them. These are not four bugs to be patched one release at a time; they are the shadow of a decision taken before the first screen was drawn. We have watched the same 'we will add offline later' assumption harden into order orchestration that needs its own ops team, and turn routine work into tens-of-minutes rituals in the spirit of SPDD, SPAU and the 35-minute transport.

The remedy is not a settings toggle; it is a rebuild of the write path. When we design order capture, stock counts and returnable reconciliation for the field, the on-device database is the product and the server sits downstream of it — which is why we treat offline-first as an architecture decision taken on day one, not a feature added after the first no-signal bug report lands.

Connectivity in the field is not improving fast enough to rescue an online-first design. The dead spots in a rural distributor's territory — the metal-roofed cash-and-carry, the third-basement cold room, the border town with one mast — are the same dead spots they were a decade ago, and they will still be there for the next hardware refresh. The apps that survive are the ones built on the assumption that the network is a lie: correct without it, honest about the gaps, and tested on the worst route in the book rather than demonstrated on office wifi. 'Works offline' should be a claim someone has to earn, not a box someone gets to tick.