A till that updates itself, carefully

A till is opened at the start of service and left. A kitchen screen runs for days. On a phone, an app pinned to the home screen can hold the same loaded code for a week. Meanwhile the software behind them moves several times a day. Without help, every fix waits for somebody to think of refreshing a browser — which is not a thing a chef with a pan in each hand will ever think of.

The mechanism is small

The server reports which version it is serving. Once a minute, each open screen compares that against the version it actually loaded — read off its own script tag, so the two cannot drift apart by a forgotten edit. When they differ, the screen announces "new version — reloading" for a couple of seconds, and reloads itself.

The refusals are the feature

A page that reloads itself is a small idea with a large number of ways to be dangerous, so the decision lives in one tested module with its refusals written down. Never with work that has not reached the server — a tick made offline waits in an outbox, and reloading mid-flight risks exactly the loss the outbox exists to prevent. Never under a finger — a sheet open, a tap seconds ago, and the reload waits for quiet. Never during the take-it-back window after finishing a ticket, because those seconds are held on the device and nowhere else. Never on an unreadable answer, so an error page cannot read as "something new". And once per version — a stale cache must not produce a screen that reloads in a loop.

The payoff showed up this week: three till fixes shipped overnight, and every screen that mattered was running them by morning without anybody being asked to do anything. The alternative is a fleet of counters each frozen at whatever day somebody last restarted them — which is the state most of this industry quietly operates in.