Offline support gets scoped as a feature roughly the way 'make it secure' does: a line item near the bottom, to be picked up once the main build is done. It never works, and the reason is structural rather than a matter of effort.
A conventional application has one authoritative copy of the data, on the server. Every client is a view onto it. Adding offline support means introducing a second place where writes can originate — and that is not a feature, it is a different data model.
The question that decides everything
Ask it early: when the local copy and the remote copy disagree, who wins, and why?
On a dairy farm, the answer is the local node, and it is not a close call. The milking parlour is where the milk is actually measured. If the office and the shed disagree about how much a cow produced this morning, the shed is right. So the Raspberry Pi running SQLite in the shed is the authority, and the cloud is a replica that catches up.
That single decision then propagates outward. Identifiers have to be generatable offline, so they are not database sequences. Timestamps have to survive a node whose clock drifted during a power cut. The sync protocol has to be idempotent, because a partial upload will be retried. None of this can be bolted on afterwards, because all of it is load-bearing.
What you get for it
- The business keeps operating at full capability during an outage, rather than degrading to paper.
- Sync becomes a background concern instead of a prerequisite for doing work.
- Latency disappears from the user's experience — local reads and writes are instant.
- You stop needing the network to be good, which is the only realistic plan in a lot of places.
The honest trade is complexity. You are running a distributed system now, and you should only accept that if the alternative is genuinely worse. For a farm that loses power weekly, it is.