Zero-Hardware Kitchen OS: Next.js PWA Case Study

This technical breakdown contains affiliate links. If you deploy this stack using my links, I earn a commission at no extra cost to you.

By Alfaz Mahmud Rizve | RevOps & Full Stack Automation Architect

It Started With a Bagel

Picture it: 8:47 on a Saturday morning. The kitchen is running hot. There are four tickets already on the rail, the espresso machine is screaming, and the flat-top has three orders of avocado toast at different stages. Then — a new order arrives. The iPad on the counter lights up. The chef — hands covered in hollandaise — has to stop, wipe down, walk over, tap through a confirmation UI, and walk back.

The eggs are now overcooked. The customer who ordered them will not come back.

This is not a UX problem. It is a revenue problem. And it was the exact problem I set out to solve when I built Urban Harvest Cafe OS — a zero-hardware, hands-free, self-managing kitchen operating system that runs on a browser tab and costs $0 to deploy.

The Problem With the Status Quo

Independent cafes are strangled by infrastructure designed for chains. A traditional Point-of-Sale setup is not just expensive — it is philosophically wrong for a solo operator.

The software industry solved "contactless ordering" for big chains with six-figure IT budgets. It left the independent operator to keep fighting a $2,000 iPad terminal that requires a dedicated staff member to operate.

Urban Harvest OS is the other answer.

The "Flour on the Hands" Constraint

Here is the design constraint that every restaurant tech company ignores because none of their engineers have ever worked a kitchen shift:

You cannot design for screen interaction in an environment where screens cannot be touched.

A professional kitchen is hot, wet, and fast. Flour, hollandaise, olive oil — these are not compatible with touchscreen interfaces. The moment a new order requires a physical tap to acknowledge, you have broken the most fundamental rule of kitchen ergonomics: the chef's hands belong on the food, not the hardware.

I spent time studying how solo operators actually move through their shifts. The pattern was consistent: the biggest workflow interruption was not cooking the food — it was the context-switch between cooking and managing orders. Every tap on a screen is a mental gear change that costs focus, time, and plate quality.

The solution was obvious once you frame it that way: the system has to come to the chef's ears, not demand the chef's hands.

The Technical Architecture

Every choice in this stack is a direct answer to a specific operational constraint.

Next.js 14 App Router + PWA — The Death of Proprietary Hardware

The customer storefront is deployed as a Progressive Web App. This decision alone eliminates the entire hardware procurement problem:

• Customers scan a QR code at the table — they are instantly inside a full-featured mobile ordering interface. No download, no account, no friction.
• The kitchen dashboard runs on any browser: a $200 Android tablet, an old laptop, literally anything with a screen. The hardware cost drops to $0.
• Service workers cache the core UI so the storefront loads instantly even on spotty cafe WiFi.
• Repeat customers can install the app to their home screen natively — no App Store, no 30% Apple cut, no submission process.

Supabase PostgreSQL + Realtime — Sub-100ms Order Dispatch

The order pipeline is built on Supabase Realtime, enabled at the database level:

-- Enable real-time WebSocket broadcast on the orders table
ALTER PUBLICATION supabase_realtime ADD TABLE orders;

When a customer confirms their order, a single INSERT fires. Supabase immediately pushes the full order payload over a WebSocket channel to the kitchen dashboard — consistently under 100ms. No polling. No page refresh. The ticket appears in the Kanban queue before the customer has even put their phone down.

The resilience layer: WebSockets are fragile in real-world environments. Browser extensions block them. React StrictMode tears them down during development. Tab backgrounding can suspend them. To guarantee that zero orders are dropped regardless of connection state, I engineered a 5-second polling fallback that runs in parallel with the live subscription. If the WebSocket drops silently, the fallback catches every missed order within one polling cycle. The chef never knows it happened.

Zustand Cart + localStorage — Orders That Survive Reality

The customer cart is managed client-side via Zustand with localStorage persistence. If a customer refreshes the page, loses mobile data mid-scroll, or accidentally closes the tab, their full cart is restored on the next page load. This is not a nice-to-have — it is a direct reduction in order abandonment.

The cart store also drives the Average Order Value progression bar: as customers add items, a gamified progress indicator fills toward spend thresholds that unlock automatic discounts. Subtle psychological commerce architecture, built into the ordering flow.

JSONB Schema — Handling Order Complexity Without Chaos

"One Avocado Toast, extra lemon, no red onion, gluten-free bread substitute." Normalizing that into relational tables creates a join-complexity nightmare. The orders table uses a hybrid schema instead:

CREATE TABLE IF NOT EXISTS orders (
  id           UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  customer_id  UUID REFERENCES customers(id),
  items        JSONB NOT NULL,
  total_amount NUMERIC NOT NULL,
  status       TEXT DEFAULT 'pending',
  order_type   TEXT NOT NULL
);

Structured fields for the queryable business data. JSONB for the infinite-variation cart payload. The analytics layer stays clean and fast; the ordering layer stays flexible and schema-free.

Row Level Security — Postgres as the Security Layer

Authentication is enforced at the database layer, not the application layer where it can be bypassed:

• Customer connections use a scoped anon key — INSERT only on the orders table. They can place orders, not read or manipulate existing ones.
• The kitchen /dashboard route is protected behind middleware-enforced session validation. No unauthenticated client gets near the queue.

The TTS Silent Unlock — Solving the Browser's Biggest Obstacle

This is the most technically elegant component in the system, and the one that took the longest to engineer correctly.

The problem is not obvious until you try to build it: modern browsers will refuse to play audio on any page until the user has made a deliberate physical gesture. No click, no audio. This is a browser-level security policy that cannot be bypassed with a permission dialog — the user must physically interact with the page first.

For a hands-free kitchen system, this is catastrophic. The chef opens the dashboard. A new order comes in. The TTS fires. Silence. The chef has no idea an order arrived. The hands-free system is broken before it starts.

The naive solutions all fail. An "Allow Audio" button requires a daily interaction. A browser permission request adds friction. A visual-only fallback defeats the entire purpose.

The engineered solution is the Interstitial State Lock.

When the kitchen dashboard loads, it does not open the WebSocket subscription. It does not start listening for orders. Instead, it renders a single fullscreen overlay — a large "Start Shift" button that the chef clicks once, at the beginning of their shift, before service begins.

That single click does two things simultaneously:

From that moment forward, every incoming order triggers the full TTS announcement automatically: "New order for Rizve, Table 4. One Avocado Sourdough Toast, one flat white." No tapping. No wiping hands. No context-switch. The chef hears it and gets back to the eggs.

The Failsafe Queue handles OS-level interruptions: if the tab is backgrounded and audio is suspended, any missed TTS payloads are queued in memory and displayed as a high-contrast visual alert banner on tab restoration. Zero dropped orders, even against system-level audio interruptions.

Dynamic Overload Protection — Software as Brand Defense

Most developers think about capacity limits as a technical constraint. I think about them as a brand protection mechanism.

Here is the scenario no POS system in the market addresses: a solo chef, Saturday morning rush, accepts 30 orders in 45 minutes. Wait times spiral to 90 minutes. A customer who waited for a bagel — a bagel — leaves a 1-star Google review: "Ordered at 9am. Got my food at 10:30. Avoid this place."

One review like that costs more in lost future revenue than any individual order is worth.

Urban Harvest OS includes a configurable Dynamic Overload Protection engine. The chef sets their maximum active ticket capacity in the Settings dashboard. The system watches the real-time count of pending and cooking tickets.

When the queue hits the threshold:

The system's job is to prevent promises the kitchen cannot keep. Protecting the brand is not the chef's problem — it is the software's problem.

Results

The live deployment is running at urbancafe.whoisalfaz.me. Full source code is available at github.com/AlfazMahmudRizve/Urban-Harvest-Cafe.

A video walkthrough — from QR scan to TTS kitchen announcement to Kanban dispatch — is in production and will be embedded here upon completion.

Related Services

• Custom Full-Stack — Bespoke internal tools, dashboards, and client portals engineered for your specific business logic.
• n8n Automation — Workflow automation for order processing, notification systems, and POS data pipelines.
• Headless Architecture — Real-time order systems built on Supabase, Prisma, and Next.js.

Designed & engineered by Alfaz Mahmud Rizve — RevOps Architect & Full Stack Automation Engineer.