The challenge
A gaming cafe is a small business with an unusually hard operational problem. It bills by time on a machine, the machines are physical PCs and consoles scattered across a floor, and the busiest hour is also the one where mistakes are most expensive. Most cafes we spoke to were running on some mix of a notebook, a spreadsheet, a till and a staff member’s memory.
- Sessions timed by hand, so bills depended on who remembered what
- No way to lock a PC when time ran out without walking to it
- Walk-ins and phone bookings colliding on the same station
- Snacks and drinks sold from a separate till with its own stock count
- One shared login for every staff member, and no record of who did what
- Owners with more than one venue unable to see the business as a whole
Requirements
- Real-time station control — lock, unlock, restart, shut down and wake every PC from the counter, instantly
- Session tracking — live timers, single and group bookings, add-ons, extensions and pauses
- Billing — rates per station type, weekday and weekend tiers, day and night rates, per-player console pricing
- Memberships and wallets — customers top up in cash or UPI and spend it on sessions or at the counter
- Inventory and point of sale — one stock count shared by the counter and the back office
- Remote management — screen view, remote control, app launch and USB policy without leaving the dashboard
- Reporting — revenue by payment method, station and day, with cash reconciliation and CSV export
- Staff access — granular roles with permissions enforced on the server, and a full audit log
The solution
We designed CR Cafe as a set of cooperating applications around one backend, rather than a single app. Each piece runs where it has to: the dashboard in the browser, the lock screen on each PC, the wake sender on an always-on machine, and the session clock on the wall beside each console.
Admin dashboard
A React 19 and TypeScript web application with a live station grid, bookings, point of sale, inventory, customers and wallets, reports, roles and settings. It supports multiple cafes per account, English and Hindi, and light and dark themes.
Backend and real-time hub
A Node.js and Express API on PostgreSQL, with a Socket.IO hub that relays commands between dashboards and stations. Every real-time handler is permission-checked on the server, mirroring its REST equivalent — an unguarded socket would otherwise be a way around the API’s security.
Station agent
An Electron kiosk app on every gaming PC. It shows a full-screen lock screen, unlocks when a session starts, reports its state back, launches games by key from a local allowlist, and supports live screen view and remote control over peer-to-peer WebRTC — so on a cafe LAN the video never leaves the building.
Wake-on-LAN relay
A tray-only Electron app on the counter PC that broadcasts Wake-on-LAN packets. It exists because a magic packet is a local-network broadcast: when every station is powered off, nothing on that network can send one.
Session displays and mobile app
ESP32 boards with a small LED or OLED display mounted beside consoles show how long a booking has been running — something a console cannot show for itself — and can beep before time is up. A React Native app gives customers their own login and profile.
Architecture
Admin dashboard (React) Mobile app (React Native)
│ REST + Socket.IO │ REST
▼ ▼
┌───────────────────────────────────────────────────┐
│ Node.js API · Socket.IO hub · PostgreSQL │
└───────────────────────────────────────────────────┘
│ Socket.IO │ Socket.IO │ HTTPS
▼ ▼ ▼
Station agents Wake-on-LAN relay ESP32 session
(Electron, per PC) (Electron, tray) displays- Agents and admins connect to the same hub, distinguished at the handshake; each agent proves it belongs to the cafe it claims with its own per-station secret
- Only a key ever crosses the wire to launch an app — the agent resolves it against its own allowlist, so a compromised dashboard can’t run an arbitrary program
- Screen view is WebRTC: the backend relays signalling only, and the video goes peer to peer
- Plans and entitlements are data, so selling a new tier is a row edit rather than a release
- Schema changes ship as versioned migrations applied on boot
We wrote up the real-time layer in more depth in building real-time station control with Socket.IO.
Engineering challenges
A kiosk that has to cover the whole screen
After an Electron upgrade, a lock window on a real station came up covering only part of the display, leaving the taskbar reachable. The cause turned out to be that newer Electron versions ignored the full-screen flags at window creation. We now create the window at the display’s exact bounds and enforce them at runtime — and never trust isFullScreen(), which reported true while the taskbar was still visible. The full story is in building a Windows lock-screen agent with Electron.
Waking PCs reliably
An early design picked one machine to send each wake packet. A relay enrolled from another building could win that pick and broadcast every wake onto the wrong network while the dashboard still reported success. Wakes now fan out to every relay and online agent in the cafe, the first confirmed success wins, and the dashboard shows which relays are connected and flags one that looks off-network. Details in Wake-on-LAN for a whole cafe.
Staying useful when the internet goes down
Because the backend is in the cloud, an internet outage takes the dashboard offline at the same moment as the stations. So staff have an offline unlock: a passphrase whose hash the agent stores and checks locally. Each offline unlock is queued and reported when the connection returns, for the audit log.
Updates that don’t hurt the game
The desktop apps update themselves, and a customer once reported in-game ping jumping from 8 ms to 1000 ms. The cause was every machine downloading an update at the same moment on the cafe’s shared connection. Station agents now defer downloads until the PC is locked, and update checks are randomly spread out rather than on a fixed clock.
Billing that never locks a cafe
For security questions, “fail closed” is right. For billing it is dangerous: a failed card retry must not lock every PC mid-session. CR Cafe’s rule is that a billing problem downgrades an account to free-tier features; it never locks one.
Results
CR Cafe is live in production at cafe.crdevs.com. What shipped:
- One dashboard for stations, bookings, point of sale, inventory, customers, wallets, staff and reports
- Instant lock, unlock, restart, shutdown and wake for every PC, individually or in bulk
- Live screen view and remote control of any PC from the counter
- Pricing per station type with weekday, weekend, day, night and per-player rates, locked in at booking time
- Server-enforced roles and a complete audit log of every action
- Multi-cafe accounts, English and Hindi, and self-updating desktop software
- Every repository deploys automatically on push, with each release announced to the team
