V0 / 2024One-off ordering form
← Back to projectsCCTMENU / OPERATIONS DEMOFrom guest order
From guest order
to kitchen fulfilment.
One operating flow connects the mobile menu, server-trusted pricing, persistent orders, and a role-scoped staff board.
Guest flowServer-trusted pricingRole-scoped actions
New orders 02#A12Pineapple bun · Milk teaAccept order
Cooking 01#A09Satay beef noodlesMark ready
Ready 01#A07Set meal · Hot coffeeNotify pickup
How an ordering exercise
became an operating system.
The upgrade is not just visual. It adds a pricing trust boundary, persistent orders, staff roles, and a complete state history.
WHAT CHANGEDServer repricingOrder transactionRole-scoped KanbanState history
V1 / NOWFront-to-back operations demo
What this project proves
AI assisted the Next.js rewrite, data model, component implementation, and testing; I defined the ordering rules, state flow, operational boundaries, and acceptance criteria.
V0 and V1 Git branches, a public guest-ordering flow, database schema, Server Actions, a staff Kanban, and status history.
Evidence trail
Last reviewed2026-08-27See what is live, bounded, and still next.
The public guest flow has been verified step by step. Signed-in staff operations remain explicitly protected rather than being presented as publicly inspectable proof.
Public menu and guest ordering
The public release exposes the menu and guest ordering flow without an account or synthetic-data login.
Modifiers, quantity, and notes
The live flow verifies structured modifiers, drink supplements, quantity changes, and special requests.
Staff Kanban and order history
The staff surface is sign-in protected. The portfolio describes roles, six states, and history design without exposing accounts, stores, or database contents.
Real merchants, payments, and multi-store operations
This remains a deployed single-restaurant concept demo with no claim of merchant adoption. Its data structure leaves room for expansion, but merchant onboarding, billing, domain mapping, and full tenant isolation are not complete.
Guest → KitchenEnd-to-end operating flow
Server-trustedServer-side repricing
6 statesTraceable order lifecycle
Problem
The original Flask version could select and price a meal, but compressed the service into a one-off form with no persistent order, role boundary, legal state transition, or staff workflow.
Build
I first reframed responsibility across guest, server, kitchen, and manager, then implemented structured modifiers, server-side repricing, transactional order creation, a role-scoped Kanban, and six-state history with Next.js, Supabase, Auth.js, and Drizzle.
Outcome
A five-minute exercise became a deployed, testable front-to-back operations demo for one restaurant. The data model leaves a path toward multiple merchants, but the current release makes no claim of merchant adoption, payments, revenue, or full tenant isolation.
How one order moves through the system
The public menu supports photographed dishes, set drinks, hot or cold choices, quantity, and notes.
Order creation reloads menu and modifier data, rejects browser-trusted pricing, and persists the order transactionally.
Staff advance orders only through legal state transitions, with payment state checked before completion.
Protected surfaces hold menu, settings, history, and reporting entry points without exposing operational data in the portfolio.