Adding offline support to a system designed for connectivity almost never works. The decision has to be made at the data model, not at the sync button.
Every few months we are asked to add offline support to a system that was designed on the assumption of connectivity. It is one of the few requests where the honest answer is usually that retrofitting will cost more than rebuilding the data layer.
Why retrofitting fails
A connected system can rely on the server as the single arbiter of truth. Two users cannot easily create conflicting records, because every write goes through one place. Remove that guarantee and a set of assumptions quietly break at once.
Auto-increment primary keys assigned by the server become unavailable at the moment of capture. Uniqueness constraints cannot be checked. "Last write wins" starts silently destroying work, because the last write to arrive is not the last thing that happened — it is just the device that found signal first.
What has to change in the data model
Three things, all at the foundation:
Identity is assigned on the device. Records need an identifier generated locally, mapped to a server identifier later. Anything that references a record has to survive that mapping.
Transactions are append-only where they represent events. A dose administered is an event. It happened at a time, in a place, by a person. It should never be updated by a later sync — only superseded by another recorded event.
Conflict rules are defined centrally and explicitly. Not left to whichever code path happens to run. For master records, that often means a supervisor reviews conflicting edits rather than the system guessing.
The part teams underestimate
The interface work is larger than expected. A user needs to know, without thinking about it, whether their device is ready for the day, how much is waiting to upload, and whether anything has failed. Get that wrong and people work around the system — writing on paper as a backup — which costs you the data quality you built the system for.
What this means for procurement
If offline capability matters to your programme, it belongs in the requirements at discovery, priced into the architecture. It is not a line item you can add in month four for a small change order, and a vendor who tells you otherwise is either misunderstanding the problem or hoping you will not notice until the invoice.