There is a persistent assumption in enterprise software that connectivity is a solved problem with occasional exceptions. Build for the connected case, add a spinner, handle the edge case later. It is a reasonable assumption in the places where most enterprise software is written.
It inverts completely in the systems we build. The head office has fibre. The gate has one contended link and a generator. The producer tagging a harvest has a phone with two bars, sometimes. And it is precisely those places where the data originates — where a record is created that everything downstream depends on.
Offline-first is a data model decision
The mistake is treating offline support as a caching layer added near the end. It is not a feature; it is a consequence of how you model writes. If your client assumes a write is confirmed by a server response, retrofitting offline means rewriting every mutation path in the product.
The alternative costs little if chosen early. Client-generated identifiers so records exist before the server knows about them. A durable local queue with explicit ordering. Conflict rules decided per entity by someone who understands the domain, not resolved generically by last-write-wins. And an interface that distinguishes captured from submitted from confirmed, because a user who cannot tell those apart will enter the record twice.
Power counts as connectivity
A related constraint that rarely appears in a specification: the device may lose power mid-transaction, and the building may lose power mid-day. Anything held only in memory is lost. Anything requiring a clean shutdown will eventually not get one.
Practically this means writing to durable local storage at each meaningful step rather than at submission, and treating every startup as a potential crash recovery. It is unglamorous, it never demonstrates well, and it is the difference between a system officers trust and one they keep a paper copy beside.
The paper ledger beside the terminal is the clearest possible verdict on a system. It means the people using it have decided, from experience, that it cannot be relied on.
Test where it will run
Throttled network profiles in a browser are a starting point, not a substitute. Intermittent connectivity behaves nothing like slow connectivity: requests do not fail cleanly, they hang, half-complete, or succeed after the user has given up and retried. We test on the actual hardware, at the actual site, on a working day — which is also how we find that the barcode scanner reads badly in direct sunlight, and that nobody can operate a two-handed interface while holding a clipboard.