Shop-floor latency is a product decision
Two-second lag kills trust in a production console. It's not a performance knob — it's the shape of the product.
- #Product
- #Realtime
- #Ops
I’ve been building a production console for a modular construction factory (Modular_OS). The piece of the product that does the most work for user trust is the one nobody ever includes in a spec sheet: the console has to reflect reality within a second.
Not “should.” Has to. If the screen in the foreman’s hand is two seconds behind the screen at the framing station, the whole thing collapses into a curiosity that people work around.
Why latency is product, not tech
Most realtime-vs-polled arguments treat the decision as a performance trade-off: realtime costs more complexity, polling is simpler, pick your point on the curve. That’s the wrong frame for a shop floor.
On a floor, the console competes with two things that are natively zero-latency:
- Walking over and looking. Any lag greater than that, and the floor lead walks.
- Shouting. Any lag greater than the time it takes to shout from one station to another, and people shout.
Polling-at-5-seconds loses both benchmarks. It doesn’t matter that 5 seconds sounds fine in a quarterly review — it’s an eternity compared to the physical alternative. The console isn’t competing with “a slower console.” It’s competing with the factory’s existing coordination system, which runs at the speed of eyeballs.
The second-order effect
The thing that surprised me: latency isn’t just about the specific moment of lag. The perception of latency is sticky. Once a user has seen the console be wrong once at a bad moment — a blocker that was cleared ten minutes ago is still red — they stop trusting the screen in all moments, including the ones where it’s correct.
Trust in a console is a ratchet: easy to lose, hard to recover. Realtime sync isn’t solving “people want fast updates”; it’s solving “people will stop looking at this screen forever if it surprises them.”
What this changes about the stack
Once latency is a product constraint instead of a tech knob, a bunch of decisions resolve without debate:
- WebSockets over polling — not because polling is slow, but because polling lies by default during the gap.
- Optimistic writes + reconcile — because the tablet user shouldn’t wait for the server to acknowledge a click before the UI moves. The floor is too fast for that roundtrip.
- Offline behavior as a feature, not an edge case — because losing Wi-Fi on a shop floor is Tuesday, not an incident.
None of those are clever engineering decisions. They’re the consequences of taking the product constraint seriously.
The lesson that generalizes
There’s a common shape here: when your software competes with a physical substitute, the substitute sets the performance bar, and the bar is almost always tighter than anything the team would set on their own. The product decision is accepting that fact up front.
For a shop floor, that looks like realtime. For a safety system, it looks like never dropping an event. For a checkout flow, it looks like sub-300ms response. Different numbers, same principle: your baseline isn’t your previous software, it’s whatever the user would do without you.