Why your bar app should work without wifi
Every app claims to be reliable. Most of them mean the server is reliable. That is a different promise from the one a busy bar actually needs.
The problem with normal web apps
A standard web app does one thing for every action: it asks the server. Tap a button, send a request, wait for the answer, update the screen. It is simple and it works, as long as the network holds.
Now put it in a bar. The router is behind the bar, three years old, and shared with the jukebox. Someone's phone is downloading an update. The signal is fine at the front and patchy by the toilets. This is the environment where a queue system has to work, and it is the exact opposite of a clean network.
When the request fails, a normal app does one of two things. It shows a spinner until the network returns, or it shows an error. Both are useless when a room is waiting to play.
What offline-first means
Offline-first means the app treats the local device as the real database, and the server as a synchronisation partner rather than a dependency.
In practice:
- Writes go to local storage first. Adding a player to the queue succeeds immediately, because it is written to the device.
- The interface never waits for the network. Reordering a queue, starting a match, recording a result: all instant, all local.
- Sync happens in the background. When a connection exists, changes flow to the server and back. When it does not, they queue up.
- The network becomes an enhancement, not a requirement. Live updates from other devices arrive when they can.
How this actually works
In the browser, the local database is IndexedDB, accessed through a wrapper library. It holds the same records the server holds: players, matches, queue state, venue configuration. A service worker caches the app itself, so the interface loads without a network round trip.
The synchronisation is the interesting part. Pool Queue pulls first, then pushes, using cursor-based pagination so a large venue does not have to transfer its entire history to catch up. Conflicts are resolved per record with a last-write-wins rule, which is the right choice for this domain: if two devices disagree about a player's name, the later edit should win, and nothing is lost that matters.
Records are soft-deleted rather than removed. A deletion on one device needs to propagate as a deletion, not as an absence, or the next sync from another device will happily restore the record. This is the kind of detail that is invisible when it works and maddening when it does not.
The failure modes that remain
Offline-first is not magic, and it is honest to say where it still bites.
| Situation | What happens |
|---|---|
| Two devices edit the same record with no connection | The later one wins on sync. The earlier edit is lost. |
| Live queue view during a wifi drop | Displays stop updating. The queue itself is safe on the staff device. |
| Device storage cleared | Local data is gone. It syncs back down on next load if the server already has it. |
| A long offline period | Changes accumulate and reconcile on reconnect. More edits means more potential conflict. |
None of these are showstoppers for a bar, because the critical path, which is the staff device managing the queue, keeps working throughout.
Why it matters commercially
If you are choosing software for a venue, this is one of the few features that is genuinely worth insisting on. Ask one question: what happens if I unplug the router right now?
An offline-first app will not notice. Most others will stop, and you will discover this on your busiest night rather than during the demo.
Last updated 16 September 2026