Mobile strategy

Offline-First Kiosks: What Happens When the Wi-Fi Dies at the Counter

A kiosk that shows a spinner during lunch rush is a kiosk that costs you orders. Plan for the network failing, then make failing boring.

Author

Published

Updated

Length

7 min · 900 words

Key takeaways

  • Treat the network as optional: the kiosk should be able to take an order with no connection.
  • A local queue stores orders and syncs when the connection returns.
  • Idempotent order submission prevents duplicates when a retry fires twice.
  • Staff need a visible sync state, not a silent failure.
  • Reliability is the feature customers never notice, which is the point.

Restaurant Wi-Fi is not a data centre. It drops, it lags, it shares a router with the card machine. The kiosk I built for SVSFood was designed with that in mind from the first screen.

A local queue, not a spinner

When an order is confirmed, it is written to local storage first and marked as pending. A background worker sends it to the API. If the request fails, the order stays in the queue and retries. The customer sees a receipt either way.

Make retries safe

Every order carries a client-generated id. If the first request actually succeeded and the response was lost, the retry hits the same id and the server returns the existing order instead of creating a duplicate. This one detail is the difference between offline mode and offline chaos.

Show staff the truth

A small sync indicator in the staff view shows how many orders are waiting. End-of-day reset is guarded by a staff PIN so nobody wipes the queue by accident.

Frequently asked questions

Do kiosks need to work offline?

In a restaurant, yes. The cost of a failed order during peak hours is lost revenue and a queue of unhappy customers. The SVSFood kiosk includes an offline mode with a local queue that syncs when the connection returns.
Offline-firstKioskReact NativeReliability

Related technical writing

Product engineering

Firing a Kiosk Vendor: Rebuilding SVSFood's Ordering Stack From Scratch

Three outlets, one vendor, a subscription per terminal and downtime nobody controlled. Here is why I replaced the whole thing with code the client owns, and what it cost to do it properly.

Mobile strategy

Why I Choose React Native: Cross-Platform Is a Strategy, Not a Weakness

I do not skip native Swift or Kotlin because I cannot write them. I choose React Native on purpose: one TypeScript codebase, shared types with Next.js, and 4–8 week mobile MVPs at a fraction of dual-native cost.

Backend architecture

One Fastify Backend, Four Clients: Kiosk, Web, Rider, Admin

Four different front ends, one API, one database. The trick is not the framework. It is deciding early that nothing gets its own copy of the menu.

Links

© LINKS °

Let's build together. Waiting to connect.

Book A Call

https://vishu.app/book

©2025Vishu Pratap · Software Developer