Cloud-only software assumes reliable connectivity. That assumption holds in an office with fibre and fails at a counter during a power fluctuation, in a warehouse with poor coverage, or in a delivery vehicle outside the city. When it fails, the business stops — and the business stopping is a far larger cost than the software.
Offline capability cannot be added at the end. It changes where data lives, how records are identified, and what happens when two devices modify the same thing while disconnected. Retrofitting it usually means rewriting the data layer, which is why it belongs in the specification rather than in a later phase.
The hard part is not storing data locally; it is reconciliation. Last-write-wins is the default in most naive implementations and it silently destroys data. A stock transfer confirmed on one terminal and a sale recorded on another are not in conflict, but a system that cannot tell the difference will discard one of them. The rules have to be specified per entity, based on what the business actually means by correct.
For a retail client we made this explicit up front: terminals operate against local data first, synchronise in the background, and resolve conflicts on defined rules. The result is that a connectivity problem is an inconvenience rather than a closed till. That outcome came from a decision made in the requirements phase, not from a library choice.