The wifi in a hall with metal racking is not the wifi in an office. It has holes, and the holes move, because a forklift with a steel pallet is a wall that walks.
So "the system needs to work offline" is not an unusual requirement in Romanian warehouses and production floors. It is the normal one. What is unusual is how differently people scope it, because most of the difficulty is not where anyone expects.
The easy part is the storage
Everybody starts here and it is genuinely the simple bit. Write locally, queue the changes, push them when the connection returns. Any competent developer builds that.
Then reality arrives in the form of four questions that have nothing to do with storage.
One: who assigns the numbers
A goods receipt gets a document number. Two devices are offline. Both create a receipt. Both want the next number.
If the number comes from the server, they cannot work offline. If it comes from the device, you get collisions. If you paper over collisions by renumbering on sync, you have changed a document number that somebody has already written on a physical pallet label, and the label is now wrong.
The workable answer is that the identity of a record and its human-facing number are different things. The identity is a UUID generated on the device, unique forever, never shown to anyone. The number is assigned by the server on sync, from a single sequence, and printed later.
Which means anything that has to be printed at the moment of creation cannot carry the final number. Usually the resolution is a device-prefixed provisional code on the physical label, and the fiscal number assigned centrally. That is a business decision disguised as a technical one, and it needs the warehouse manager in the room, not just the developer.
Two: what happens to stock
Two devices, both offline, both take the last item from the same location.
There is no clever algorithm here. The stock was wrong the moment the second person picked, and no reconciliation strategy invents an item that does not exist. What the software can do is make the discrepancy visible immediately on sync, attribute it to two specific movements, and put it in front of a human.
What it must not do is silently pick a winner. We have seen systems where last-write-wins quietly discarded a movement, and the warehouse spent months believing in a stock figure that had been overwritten by arithmetic.
The honest design goal for offline stock is not consistency. It is auditable inconsistency: every movement survives, conflicts are flagged rather than resolved, and somebody decides.
Three: the hardware
Scanners, scales and label printers are attached to the machine, not to the network, which is the actual reason a desktop application keeps winning here.
A browser cannot talk to a serial port, and the workarounds are worse than they sound: a helper service on localhost, a vendor plugin, a print-to-PDF-then-open dance that adds four seconds to an operation performed nine hundred times a shift. Four seconds times nine hundred is an hour a day, per station.
A native application opens the port. That is the whole argument, and it is why we still write desktop software for this class of work in a period when almost everything else is a web page.
Four: the clock
Two devices, both offline, disagreeing about the time. One of them has been on a shelf since March and has drifted.
Every offline record should carry both the device clock and the sync-time server clock, and ordering that matters should use the second. This sounds pedantic until you have a dispute about whether a receipt happened before or after a stock count, and the only evidence is a timestamp from a machine that was forty minutes fast.
Intermittent faults of this kind are almost never what they first appear to be, which is a lesson we learned expensively elsewhere.
What to tell the person paying for it
Offline capability is not a feature you add. It is a property of the data model, and retrofitting it means changing how identity, numbering and conflict work, which touches everything.
So it is worth being direct at the estimate stage: if the work happens where the network is unreliable, offline is a structural requirement and it changes the price. If it happens at a desk with cable, it does not, and paying for it is paying for complexity you will maintain forever and never use.
The middle case is the one to be careful about, where somebody wants it "just in case". That is the most expensive version, because you build the whole mechanism and never exercise it, so it does not work when it is finally needed. Offline code that is not used daily is offline code that is broken and does not know it.