Offline collection: what breaks

Offline collection is not a feature. It is a set of failure modes you agree to handle. The marketing version is a phone working with no signal. The real version is a phone working with no signal, rejoining a network that is hostile, in the hands of a person whose day does not revolve around your data. These are the failures that recur, and what handling each one actually takes.

A flat battery, unsynced

A monitor covers a full morning on one charge, collects nine records, and the phone dies at two in the afternoon before any sync. If the app holds records only in memory, they are gone. A real system writes every save to disk the moment it happens, so a dead battery ends the session, not the data. When the phone comes back on, the nine records are still there, marked unsynced, and the monitor can see that before starting anything new.

Ninety seconds of signal

Signal in the field is not on or off. It returns for ninety seconds at the edge of a market and disappears again. A naive uploader starts a full sync, gets interrupted, and starts over next time. A real one uploads in small batches, resumes instead of restarting, and treats a partial sync as a success to build on. Ninety seconds is enough for forty text records. It is not enough for photographs, which is why photographs go last.

The same household, twice

Two enumerators working adjacent streets both log the same household, one at 11:04 and one at 11:31. Neither is wrong; the household was on both lists. Later it looks like two households served, and the coverage number is quietly inflated. The fix belongs on the server, when both records arrive, not in a spreadsheet at export time when the enumerator context is gone.

• Deduplicate on stable identifiers, a household ID or a GPS point plus a name, never on free text.
• Flag near-duplicates for review instead of silently merging, because two brothers one street apart are two households.
• Keep both records and the merge decision, so an auditor can see what was combined, when, and by whom.

Photos that will not upload

A verification photograph is the evidence behind a number, so the system cannot quietly drop it, and it cannot let it block everything else either. The answer is to move media on its own queue, at its own pace, compressed before it leaves the phone, and to mark the record as photo pending rather than complete. The dashboard shows the number with a flag, and the flag clears when the photograph lands. A number waiting on its evidence should say so.

A form update mid-flight

You publish a form update on Tuesday. On Wednesday six phones sync before leaving for the field and four do not. Now ten enumerators are asking two versions of the income question, and the endline does not pair with the baseline. This is the failure nobody demos.

• Version every form, and keep every version readable forever, not just the current one.
• Stamp the form version onto each submission, so mixed data is detectable rather than discovered in analysis.
• Treat a form change as a scheduled event, with a sync deadline before the next field day and a check that every device made it.

A team that cannot confirm a device is on the current version should assume it is not.

A phone with the wrong clock

Halfway through a deployment you find records stamped 2024. Somebody swapped a battery, the phone reset, and nobody reset the clock. The records are real, but the period they claim to belong to is wrong, and a monthly report counts them in the wrong month. A real system does not trust the device clock alone. It keeps the time of capture as recorded, checks it against the server at sync, and flags records whose device clock drifted, so a human decides the true date instead of the phone deciding silently.

The honest summary

None of these problems is exotic. Every one of them corrupted a dataset somewhere this month. The difference between a tool that works offline and one that merely says so is exactly this list: writes that survive a dead battery, syncs that resume, deduplication on the server, media on its own queue, form versions that never strand a submission, and clocks that get checked. Ask a vendor what happens in each case. The specifics of the answer tell you everything.