Portfolio ProjectRestaurant operations

Seatly

Every seat, in sync.

Seatly is the front-of-house tool a host stand runs during service. A live floor plan shows every table's status, a timeline lines up the evening's reservations, and a waitlist quotes honest wait times. Every staff tablet sees the same floor within a moment of any change.

  • React.js
  • TypeScript
  • Laravel
  • PHP
  • MySQL
  • WebSockets
  • REST API
Live floor plan. Interface designed and built by Vikrant..

Overview

Business problem
On a busy Friday the host stand runs on a paper chart, a reservation app on one device and memory. Tables turn faster or slower than planned, a walk-in gets promised a table that a booking already holds, and nobody can say with confidence when T04 will be free.
Product objective
Give the whole front of house one shared, live picture of the room, so seating decisions are made from the same facts by every person holding a tablet.
Target users
Hosts seating guests, floor managers rebalancing sections, and owners reviewing how a service went. Used standing up, on a tablet, in a dark dining room.
Solution
A tablet-first web app centred on a floor plan. Table status, the reservation timeline and the waitlist all read from one seating service, and every change is broadcast to every device on the venue channel. This is staff-side floor operations, a different product from a consumer booking site.

Project classification

Project type
Real-time operations web app
Industry
Restaurant operations
Frontend
React SPA (tablet-first), TypeScript, canvas-style floor view
Backend
Laravel API with event broadcasting over WebSockets
Database
MySQL
Architecture
Real-time operations app: REST for commands, WebSocket channel for state fan-out

User roles

  • Host / Hostess
  • Floor Manager
  • Owner
  • Admin

My role

  • Designed the seating service rules: conflict checks, table combinations and capacity limits.
  • Built the Laravel REST API and the broadcasting layer that fans table state out to devices.
  • Designed the MySQL schema for venues, floors, tables, reservations, waitlist and service events.
  • Built the React frontend: floor view, timeline, waitlist, layout editor and guest drawer.
  • Worked out the optimistic-update and reconciliation approach for flaky restaurant Wi-Fi.
  • Role-based access for hosts, floor managers, owners and admins.

Key features

  • Live floor plan. Interface designed and built by Vikrant..

    Live floor plan

    Tables are drawn as positioned shapes that match the real room. Each shows its status (Available, Reserved, Seated, Cleaning or Blocked), party size and time seated. The right panel keeps the next arrivals and the waitlist in view so a host never leaves the floor to decide who goes where.

  • Reservation timeline. Interface designed and built by Vikrant. Bookings by table across the dinner service.

    Reservation timeline

    A table-by-time grid lays the evening's bookings out as bars, with expected turn windows. Gaps show where a walk-in fits, and a conflict is visible before it happens, not when two parties arrive together.

  • Waitlist and quote times. Interface designed and built by Vikrant. Quotes derive from tables due to turn.

    Waitlist with quote times

    Walk-ins join a queue with party size and preferences. Each entry carries a quoted wait that comes from the tables actually due to turn, not a guess, and can be texted or called to the guest with one tap.

  • Layout editor. Interface designed and built by Vikrant. Drag handles resize and move tables.

    Drag-and-drop layout editor

    Managers arrange tables, set capacities and define which tables can be joined for larger parties. Layouts are saved as named versions, so a Friday layout and a private-event layout can be swapped without redrawing the room.

  • Guest details and table transfer. Interface designed and built by Vikrant. Guest notes, check-in and table transfer.

    Guest details and table transfer

    A guest drawer holds party notes, allergies, occasion and visit history, with check-in and table transfer beside them. Transfer shows only tables that are free for the remaining duration, so a move cannot create a clash.

  • Shift summary. Interface designed and built by Vikrant.

    Shift summary

    At close, covers, average turn time, walk-ins seated, waitlist conversion and no-shows are summarised for the floor manager and owner, with a service log of the notable events of the night.

Also in the product

  • Live floor plan with five table statuses
  • Reservation timeline across tables
  • Walk-ins and waitlist with quote times
  • One-tap check-in and table transfer
  • Drag-and-drop layout editor
  • Guest details and service notes
  • Capacity rules and table combinations
  • End-of-shift summary

User flow

  1. Host opens the floor view at the start of dinner service and sees the room as it stands.
  2. A reserved party arrives; the host taps their name and checks them in.
  3. Seatly suggests tables that fit the party and are free for the expected duration.
  4. The host seats the party; the table turns blue on every device in the room.
  5. A walk-in is added to the waitlist and quoted a wait based on tables due to turn.
  6. When a table is cleared and reset, it returns to Available and the next waitlist party is offered it.
  7. A floor manager transfers a party to a larger table when a guest joins late.
  8. At close, the shift summary is reviewed and the service log is archived.

Technical architecture

  1. React SPA on staff tablets (floor canvas, timeline, waitlist)
  2. REST API (Laravel) for commands and queries
  3. WebSocket channel per venue for live state broadcasts
  4. Seating service: conflict checks, capacity rules, table combinations
  5. Waitlist estimator: turn-time model per party size
  6. MySQL: venues, tables, reservations, waitlist, service events
  7. Broadcast fan-out to every staff device on the venue channel

Database and backend

Realtime broadcasting

  • Every mutation goes through the REST API and, once committed, dispatches a broadcast event on a private channel scoped to the venue.
  • Events are small deltas (table id, new status, version) instead of whole floor snapshots, so tablets patch local state cheaply.
  • Each table row carries a version counter; a device that misses events detects the gap and refetches the floor.
  • Channel authorisation checks the user's venue and role before a device can subscribe.

Seating conflict checks

  • A seating request locks the target table row inside a transaction, then checks overlapping reservations, active seatings and blocks for the expected duration.
  • Party size is validated against table capacity and any allowed table combination.
  • A conflict returns 409 with the clashing reservation, so the UI can show why and offer alternatives.
  • Transfers run as one transaction: release the old table, claim the new one, record a service event.

Waitlist estimator

  • Quote times start from each occupied table's seated time plus the average turn time for its party size.
  • The estimator finds the earliest table that fits the waiting party, with reserved arrivals counted before walk-ins.
  • Average turn times are recomputed from completed seatings in the venue's own history, per shift.
  • Quotes are stored with the entry, so the host can see how a promise compares with what happened.

Data and access

  • Entities: Venue, Floor, Table, TableCombination, Reservation, WalkIn, WaitlistEntry, Guest, Shift, ServiceEvent, Note.
  • Layouts persist as versioned JSON plus normalised table rows, so editing never touches live service data.
  • Role policies: hosts act on service state, floor managers edit sections, owners see reports, admins manage venues.
  • Service events form an append-only log used for the shift summary and for debugging disputes.

Challenges and solutions

  • Keeping table state consistent across several tablets

    Commands go through the API and state flows back over the venue channel as versioned deltas. A version gap triggers a snapshot refetch, so a tablet that dropped off Wi-Fi recovers on its own.

  • Conflict-free table transfer

    The transfer runs in a single transaction with row locks on both tables. The destination is checked for overlapping bookings across the remaining duration, and the UI only offers tables that pass.

  • Persisting drag-and-drop layouts without jitter

    Positions are updated locally while dragging and sent as one batched save on release, snapped to a grid. Saves create a layout version, so a bad edit can be reverted.

  • Honest waitlist quote times

    Quotes come from actual turn-time history per party size, with reserved arrivals counted before walk-ins. Ranges are shown rather than a single number, and recorded for comparison with real wait.

  • Optimistic UI that can be wrong

    Taps update the screen immediately and are tagged with a client mutation id. If the server rejects the change, the table snaps back and a short message explains the conflict.

  • Usability on a tablet during service

    Large touch targets, mono table IDs and times, status shown by colour and label together, and a layout that keeps the next action within thumb reach on a landscape tablet.

Results

  • One shared, live picture of the room replaces the paper chart and the memory-based handoffs.
  • Seating clashes surface as clear conflicts before guests are walked to a table.
  • Quote times are based on how tables actually turn, which makes them easier to defend at the door.
  • Layout changes are made once by a manager and reach every device without a restart.
  • The shift summary turns a night's service log into something an owner can read in a minute.

Qualitative outcomes only; no usage or revenue figures.

Visual identity

  • Primary #F2B84B
  • Secondary #14171D
  • Accent #38BDA7
  • Background #0E1116

Space Grotesk for interface text, JetBrains Mono for table IDs and times. Chair-in-circle monogram with a plain wordmark. Dark tablet-landscape UI with large touch targets, a floor canvas and a persistent right panel.

  • Portfolio ProjectProfessional services (multi-vertical)

    Slotwise

    Scheduling SaaS for any business that sells time: calendars, availability rules and automated reminders.

    • React.js
    • Laravel
    • PHP
    • MySQL
    • REST API
  • Portfolio ProjectRestaurant / hospitality

    Tavolo

    Restaurant booking platform. Discovery, live availability and a floor-aware dashboard for restaurants.

    • Laravel
    • PHP
    • MySQL
    • REST API
    • Tailwind CSS
    • JavaScript