Table Tap
Speculative QR-code table ordering for sit-down restaurants — customer scans the QR on the table, browses the menu, orders directly to the kitchen. Complementary to a traditional POS, not a replacement.
Overview
Table Tap is a speculative concept for QR-based customer self-ordering in sit-down restaurants. Unlike Perfect Plate (our real kitchen POS where waiters enter orders), this design puts the menu in the customer's pocket and pipes orders directly to the kitchen. It's a different product entirely — and the case study below is how we'd approach it if a restaurant partner came to us. Not shipped.
The problem
At a busy sit-down restaurant, order-taking is the single biggest bottleneck during the dinner rush. A waiter takes 4-6 minutes per table to walk over, wait for the group to decide, write it down, and carry it to the kitchen. Multiply by 20 tables and that's 80-120 minutes of waiter time consumed by order entry alone — time not spent on service, bill-splitting, or upselling. Existing QR-order apps (Dineout, Petpooja customer) are either tied to a larger ecosystem the restaurant doesn't want to join or assume a data model (franchised chains, centralised menus) that doesn't fit an independent family restaurant.
What we built
- Menu lives at a restaurant-scoped URL (e.g. perfectplate.in/t/T4) that opens instantly in a mobile browser — no app install, no account creation. Customer scans, sees the menu, starts building an order in 5 seconds.
- Built as a PWA so return customers get a home-screen icon, offline-cached menu, and push notifications when the food is ready — without ever going to an app store.
- Order submits via Firebase Function to a Firestore collection, which a Kotlin-based kitchen display tablet subscribes to in realtime. New orders ping the kitchen in under 1 second — faster than a waiter could walk the docket.
- Waiter still owns service: when the customer submits, the waiter's app on a separate device sees the order too, carries drinks, checks spice level in person, closes the bill. Removes order-entry friction without removing the humans.
- Multilingual menu (English / Hindi / Telugu / Tamil) auto-switches based on the phone's system locale. Item names stay in the original script, descriptions translate. Reflects how we actually talk about food — you don't translate 'dosa', you translate 'served with sambar and coconut chutney'.
Key features
- QR-to-menu in 1 scan — no app install, no account, instant load
- PWA: returning customers get a home-screen icon + offline menu cache
- Orders land in the kitchen in <1 second via Firestore realtime listeners
- Multilingual menu (English / Hindi / Telugu / Tamil) auto from phone locale
- Waiter dashboard sees every order — service stays human, entry gets automated
- Custom request field per item ('less spice', 'no onions') that speaks to the kitchen, not an algorithm
- No payment integration by design — waiter still closes the bill, upsell moment preserved
- Restaurant-scoped URL → different restaurants just subdomain, no multi-tenant auth complexity
Results
Concept, not shipped. What exists: a Figma design file with the customer menu and kitchen display, a prototype of the customer flow wired to a mock Firestore, an architecture document, and this case study. If you run a sit-down restaurant (especially one that already has a POS like Perfect Plate's) and order-entry during rush is your real bottleneck, talk to us.
A concept design for a cloud-menu that lives at a restaurant-scoped URL (e.g. perfectplate.in/t/table-4), opens instantly in the browser with no install, lets the customer build an order, sends it straight to the kitchen display. Waiter still handles service, payments, and upsells — but reclaims the 10 minutes of order-taking at a peak rush.
During dinner rush my waiters are running. Half their time is writing down orders. If the customer writes it themselves the waiter can actually serve.
What we learned
- QR ordering is often framed as waiter-replacement. The better framing is order-entry replacement — let the waiter do service (the human part), let the customer do data entry (the rote part).
- PWA beats native app for this. An 'install our app to see the menu' dialog kills conversion harder than any menu layout problem.
- Payment integration was the fork in the road where this could have become a Big Product. Keeping it out (waiter still closes the bill) kept the scope honest and kept the upsell moment human.
Stack
Have a similar project?
Tell us what you're building and the deadline. We'll reply in 24 hours — with either a scoped proposal or an honest "not our fit".