Offline-first design for factory-floor systems — building for the Wi-Fi that will drop

Run a factory-floor system on mobile in Thailand for real, and the line Wi-Fi will drop somewhere. Between the steel racks, behind the big machines, on the far side of a concrete wall. On some sites, right at lunch break, two hundred workers pull out their phones at the same time and the shared uplink thins to a trickle for twenty minutes.

Design a system on the assumption that the network is always up, and the line will stop. This column is a set of practitioner notes from Thai-factory projects we've worked on — including our shipping-line QC scan system — on designing factory-floor systems that treat "the network is down" as a normal state, not an exception. Told through the actual scenes we've seen on the floor.

Three ways it usually fails

Even in systems that were "built to handle offline," we keep seeing three specific failure modes once they start running in production.

1. The screen freezes the moment the network drops

The operator scans, taps "confirm", and a loading spinner keeps turning in the middle of the screen. They want to move to the next box, but the system will not let them. Thirty seconds later they give up, refresh the screen — and the previous scan is gone.

This is what happens when the system just quietly waits for the server to reply. The moment the connection drops, the wait never ends. From the operator's side, the entire system has "gone quiet".

2. It looks like it is working, but nothing is being saved

This one is worse. The operator scans, sees the confirmation screen, moves on. They believe they are doing their job perfectly. An hour later, the line manager checks the dashboard in the office and sees zero scans recorded for the last hour.

Under the hood, the system has been writing to the device's local memory only. Nothing has reached the server. And the operator's screen showed no sign that anything was wrong. By this point, the damage is done — a truck has already left with a box that was supposed to be inspected, but has no matching record on the server.

3. When the signal comes back, data gets duplicated or overwritten

The connection is restored, and all the queued scans fly out at once. Two things go wrong here on a regular basis. First, an operator who tapped the submit button a few extra times in frustration ends up with the same scan recorded two or three times on the server. Second, the manager updated a setting in the office while the line was offline, and a stale copy from the phone silently overwrites it during the sync.

These three fail in different places, so each needs its own fix. Here is how we actually build our factory-floor systems for each of them.

Fix 1. Give every action a jersey number, on the device, before it leaves

The moment an operator submits a scan, a report, or an approval, the system assigns that action a unique identifier — think of it as a jersey number that only that one action carries, ever.

When the action eventually reaches the server, the rule is: "If an action with this identifier has already been recorded, do nothing." Tap the submit button three times in a hurry, let the connection retry the same request twice — the server still records exactly one entry.

The critical detail is that the identifier is decided by the device, not by the server. If you design it the other way — the phone asks the server for a number, then submits — the moment the network is down, the phone cannot even start the action. All the effort put into offline handling collapses at the first step.

Fix 2. Do not tell the operator they are offline

Putting an "offline" icon or banner on the screen feels helpful. On a factory floor, it usually backfires.

An operator scanning boxes from morning to evening should not be forced to check "are we connected right now?" between every scan. The moment they start to wonder "was that an error because of me, or because of the network?", the pace of the whole line slows down. And in our experience, once operators start distrusting the system, they also start writing things down on paper "just in case" — which defeats the entire point of the system.

Our preferred approach is the opposite. From the operator's screen, we remove any indication of online / offline at all. When they scan and tap "confirm", the action is safely recorded on the device itself and the screen moves on. In the background, an entirely separate part of the system is quietly responsible for delivering it to the server. As far as the operator can tell, the system is just working — the same, always.

On the office dashboard, however, we do show it clearly: "47 scans have not yet reached the server, oldest one 12 minutes ago." Two different audiences need two different signals. The operator needs to keep the line moving. The supervisor needs to know when there is a backlog — and when to stop the line themselves if the backlog is getting dangerous.

Fix 3. Sync differently for different kinds of data

"Whatever the server received most recently is right" is easy to implement. It is also a great way to lose money in production. Different kinds of data deserve different rules.

Data that is only ever added, never changed

Inspection logs, scan history, work reports. Once written, they do not change. Order does not really matter — new entries just get added to the pile. Nothing collides. This is the easiest category to handle, and honestly, most of the "offline data" in a factory system falls here.

Data that can be edited

Part information, user permissions, unit prices. "Last write wins" here goes wrong like this: at 10 am, the office manager changes the unit price of Part A. At the same time, a shipping-line phone is offline and still holds the old price of Part A in its memory. At noon, the phone comes back online and dutifully sends up "here is the Part A I have" — and quietly reverts the price the manager changed that morning. Nobody notices for a week, until the accounting team wonders why an invoice went out at the old rate.

The fix is to attach a version number to every editable record in the system, and refuse to accept updates that are based on an older version than the server currently holds.

Data that gets accumulated

Worker A puts 5 pieces in the box, worker B adds 3 more to the same box. If each phone sends up an absolute value — "the box has 5", "the box has 3" — the later one overwrites the earlier one and the total is wrong.

For this kind of data, we design the system to send the change instead: "+5" and "+3". The server adds them up. Order does not matter, retries do not matter, the final total is always right.

Fix 4. During development, cut the network cruelly

None of this design work is enough on its own. You have to actually try it, on a real device, with the network deliberately turned off at hostile moments.

Three test scenarios we always run:

1. Cut the network mid-action. Right after the operator taps submit. In the middle of a scan. Just as the next screen is transitioning in. The "surely it will not drop here" moments are the ones that catch the bugs.
2. Queue 5 – 10 actions offline, then reconnect all at once. On a real floor, this happens when Wi-Fi has been down for half an hour and then comes back. Everything that piled up flies out simultaneously. Make sure the system survives the avalanche.
3. Two devices, same record, both offline, both reconnect at the same time. This is the scenario that hurts the most in production. Simulate it on purpose.

Most of the bugs that "we only saw in production" get caught up front if these three scenarios are hit deliberately during development.

Wrap-up

When you are designing a factory-floor system for Thailand, start from "the network will go down, and being down is a normal state", not from "the network is usually up, and sometimes it drops." That single shift in assumption changes every decision downstream.

The four fixes above — device-side identifiers, hiding offline from the operator, per-data-type sync rules, and hostile testing during development — cut down the "the line stopped after go-live" phone calls dramatically. Especially in the industrial estates around Bangkok and the Eastern Seaboard, where a base-station glitch during the rainy season can drop LTE across an entire block for half an hour, any system that assumes a perfect network eventually breaks.

Related: Factory shipping-line QC scan system / Factory operations improvement service

Considering a factory-floor system for your operation in Thailand? Talk to us.