Skip to content
All insights
KiosksEmbedded

What a kiosk actually has to survive

Aaron WylieDecember 11, 20247 min read

The touchscreen interface is the easy part of a kiosk project. The hard part is a device that recovers from a power cut, a dead network, and someone determined to escape to the desktop.

Clients usually arrive with a design for the screen. That design is maybe fifteen percent of the work. A kiosk is an unattended computer in a hostile environment, and almost everything that makes the project hard is invisible in the mockup.

It will lose power mid-transaction

Not maybe. Someone will unplug it to vacuum. The question is what state the device is in when it comes back, and the answer needs to be "the attract screen, with no partial transaction persisted and no filesystem corruption".

That means journaled or read-only filesystems, boot-time integrity checks, and never treating a write as committed until it is genuinely durable.

The network will go away

Venue WiFi is not reliable and cellular backhaul is worse indoors. A kiosk that shows a spinner when the network drops is a kiosk that looks broken to every passer-by.

Design for offline first: cache what is needed to keep operating, queue what needs to go upstream, and reconcile on reconnect. The interesting design questions are about what the device is allowed to promise a user when it cannot reach the server.

Someone will try to break out

Not usually maliciously - often just curiosity. But a kiosk that can be escaped into a desktop session is a data-protection incident waiting to happen.

  • Lock down the OS shell, not just the browser
  • Disable keyboard shortcuts, right-click, developer tools, USB storage
  • Blank the screen on lid or input events you did not design for
  • Time out to attract mode aggressively

You will not be standing next to it

The estate is the real product. You need remote health reporting, remote reboot, remote content updates, and enough telemetry to know a device is misbehaving before a customer tells you.

The build that only works when a developer can walk over to it is not finished, it is a prototype with a nice front end.

Ready to build something that lasts?

Tell us what you are trying to ship. We will tell you how we would approach it - scope, stack, and timeline - before you commit to anything.