Web Development — Case Study

QLess — Multi-Tenant Real-Time Pre-Order & Queue Management Platform

A production-deployed SaaS platform where any food vendor can onboard, publish a menu, and run live order queues — with per-tenant data isolation and realtime token broadcasting built in from day one.

RoleFull-Stack Developer
TypeMulti-tenant SaaS
StackNext.js + Supabase Realtime
StatusProduction-deployed

One platform, any number of vendors

QLess as an engineering project is a platform, not a single app: any food vendor can sign up, publish their own menu, and manage their own live order queue — without vendors seeing each other's data.

The engineering challenge is different from a single-shop app: the same codebase and database need to safely serve many independent vendors at once, each with their own staff dashboard, menu, and customer queue, while customers get instant, no-login access via QR code. (This platform build shares its product roots with the QLess design case study — see the UX/UI case study for the single-shop experience this was designed around.)

How it's built

Multi-tenancy

Postgres Row-Level Security policies enforce per-tenant data isolation at the database layer, so a vendor's menu, orders and staff accounts are structurally unreachable by any other tenant's queries.

Realtime queue & tokens

Supabase Realtime powers live token broadcasting — as orders move through the queue, both the staff dashboard and customer-facing token display update instantly, no polling required.

Customer access

Customers reach their order and live token status via a QR-based access flow — no account creation, no app install, just a scan.

What it's built with

Frontend
Next.jsStaff dashboard UI
Backend
SupabasePostgres RLSRealtime
Access
QR-based customer accessMulti-tenant onboarding
Live production-deployed, real vendors onboarded
N-tenant any vendor can self-onboard independently
RLS enforced per-tenant isolation at the database layer
QR zero-login customer access
01

Multi-tenancy has to be a schema decision, not a query filter

Enforcing isolation through RLS at the database level, rather than trusting application code to filter correctly, was the difference between "probably safe" and actually safe.

02

Realtime is a UX feature disguised as infra

Live token broadcasting wasn't just a technical nice-to-have — it directly created the "no queue" feeling that makes the product worth using.

03

Frictionless access drives adoption

Removing account creation entirely in favor of QR-based access measurably lowered the barrier for first-time customers to actually use the queue system.