PlayDesk
PlayDesk is a SaaS product we built and run ourselves for multi-location game and entertainment venues — proof that we can design and operate real-time systems in production, not just describe them in an architecture diagram.
The problem before PlayDesk
Game and entertainment venues running timed sessions — gaming lounges, recreational venues with food and drink service — were running session tracking and point-of-sale as two disconnected systems, with no live view connecting a customer's table, their game session, and their order.
The existing workflow
Staff tracked session time on a stopwatch or a whiteboard, took food and drink orders by walking the floor, and rang them up on a POS that had no awareness of which table or session the order belonged to. Kitchen staff found out about an order only when a physical ticket or verbal call reached them.
Problems encountered
- −Lag between an order being placed and the kitchen finding out about it
- −Session billing and food/drink billing living in two disconnected systems
- −No consolidated reporting across multiple venue locations
- −Customers having to physically flag down staff to place every order
One real-time system for sessions, orders, and the kitchen
PlayDesk unifies session/table management, customer ordering, and kitchen fulfillment in a single real-time system, so a session, its orders, and its bill stay in sync the moment anything changes — without a member of staff acting as the manual link between them.
A real-time system built on persistent connections, not polling
PlayDesk is built around Socket.io so that a change on one screen — a new order, a session ending, a kitchen ticket marked complete — appears instantly on every other screen that needs to see it, across every table and location in a venue.
- Socket.io-based real-time layer for live session, order, and kitchen state
- Customer-facing QR-based PWA for placing orders directly from the table
- Multi-location and multi-game-venue management from one operator dashboard
- Session billing and itemized order billing unified into a single bill per table
Major features shipped to production
Real-time session and table management
Live status of every table or game session across a venue, updating instantly as sessions start, extend, or close.
QR-based customer ordering
A customer-facing PWA that lets a guest browse the menu and order directly from their table by scanning a QR code, without needing to install an app.
Live kitchen display
Orders appear on a kitchen-facing screen the moment they're placed, replacing paper tickets and verbal call-outs.
Unified session + order billing
Time-based session charges and itemized food or drink orders combine into a single, accurate bill per table instead of two separate tabs.
Multi-location management
An operator running several venues gets one dashboard across all of them, instead of managing each location's POS in isolation.
Integrations:
Payment terminalsReceipt printersKitchen display hardwareHow it was built
Discovery
Walked the floor of a live venue to see exactly where the gap sat between a customer's order, the kitchen, and the till — rather than designing from a generic POS template.
Architecture
Chose a Socket.io-based real-time architecture over a polling-based approach, and designed the session-plus-order billing model so the two could never fall out of sync.
MVP build
Shipped session tracking, QR ordering, and the kitchen display first, since those three together closed the biggest gap in the existing workflow.
Iteration
Added multi-location management once the single-venue workflow was proven in day-to-day use.
What was genuinely hard about this
Keeping real-time state consistent across many concurrent sessions
A busy venue can have dozens of tables and sessions changing state simultaneously — the real-time layer had to keep every connected screen consistent without introducing lag that staff would notice during a rush.
Unifying time-based and itemized billing into one model
Session time and itemized food orders are fundamentally different billing shapes; merging them into a single accurate bill per table required a billing model designed for both from the start.
Kitchen displays staying usable through connectivity drops
A kitchen display losing its connection mid-service is worse than not having one — the client had to handle reconnection and state resync gracefully rather than silently dropping orders.
What changed
- Orders reached the kitchen the moment they were placed instead of after a staff member physically relayed them
- Session and order billing combined into one accurate bill per table, removing a recurring source of billing disputes
- Operators running multiple locations gained a single real-time view instead of checking each venue separately
Full walkthrough, screenshots, and further detail available on a discovery call.
Tech stack
Lessons learned
- →A persistent-connection architecture earns its complexity in any venue where staff are moving faster than a page-refresh cycle can keep up with
- →Billing models that unify time-based and itemized charges need to be designed together, not merged after the fact
- →Real-time systems in a live venue need graceful reconnection built in from day one — a dropped connection during service is a worse failure mode than a slow one
Questions about this project
Is PlayDesk a client project or a product Sword Tech Labs operates?
We built and operate PlayDesk ourselves. It's a live example of the real-time architecture and production operations experience we bring to SaaS engagements that need more than request/response APIs.
Why build on Socket.io instead of simple polling?
A venue has many tables and sessions changing state at once — polling either lags behind what's happening on the floor or hammers the server with requests. A persistent-connection architecture keeps every screen in sync in real time without that trade-off.
Can you show a live walkthrough or more detail?
Yes — we go deeper on the architecture and current state of the product on a discovery call rather than publishing every detail here.
Want SaaS built with this level of care?
The engineers who built PlayDeskare the same senior engineers who'll scope and build your SaaS product.