Most software engineering guidance is written in places where electricity is continuous and connectivity is assumed. A great deal of it stops being good advice when neither holds.
The assumptions that break first
Applications that expect a persistent connection, that hold important state only in memory, or that treat a failed request as an exceptional case will behave badly in an environment where the power goes and the device dies mid-transaction. So will anything that requires a large download before it becomes useful.
The patterns that hold up are the ones built for interruption: local-first storage that syncs when it can, operations designed to be safely repeatable, small initial payloads, and interfaces that tell the user honestly what has and has not been saved. None of these are exotic. They are simply not the default in most tutorials.
What it costs a business
Backup power is a capital cost and a running one, and it applies to offices, to agent networks and to anyone operating physical premises. That cost shows up in the price of the product, which puts businesses in less reliable grids at a permanent disadvantage against competitors who never think about it. It also shapes hiring: distributed teams working from home push the problem onto individual employees, who solve it unevenly.
The upside nobody plans for
Products built to work through interruption tend to work extremely well when conditions are good. Offline-capable software, aggressive caching and small payloads are precisely what makes an application feel fast on a good connection as well as usable on a bad one. Engineering teams that treat constraint as a design input rather than a hardship often end up with a better product than they would have built with unlimited assumptions.
