Working prototypeProject profile 05 · Sarcastic restaurant operations

SIC Pizza POS

A mobile-first tableside POS and collaborative-ordering prototype that carries diners, configured items, guest proposals, kitchen status, split payments, and an intentionally sarcastic brand voice through one restaurant workflow.

Operating signal

Keep the personality loud while pricing, approvals, kitchen state, and payment boundaries stay literal

Where this pattern fits

Industries and applicable uses

The interface and operating record would be configured around the terminology, decisions, and constraints of each business.

Independent restaurantsPizza shopsBars and taproomsFood hallsPop-ups and eventsMulti-location concepts

Tableside point of sale

Give servers a responsive floor, table, diner, modifier, pricing, review, and kitchen-submission path that works across handheld and desktop-sized screens.

Collaborative guest ordering

Let guests join a table without an account, view the shared order, and propose items while preserving employee approval before anything reaches production.

Kitchen display workflow

Carry confirmed items into a constrained submitted, making, ready, and served lifecycle so front- and back-of-house views share the same operational state.

Split payment and audit trail

Model diner-level allocations, tips, payment-provider boundaries, and append-only actor history before introducing certified payment processing or reconciliation.

Open the interactive prototypeUse the current browser-runnable vertical slice to explore employee access, floor, ordering, kitchen, guest, payment, and history views.Workflow automationExplore how ordering, approvals, kitchen transitions, notifications, and exception handling can become one controlled operating flow.Review the source and architectureInspect the public repository, domain rules, persistence schema, implementation boundaries, and phased production backlog.

Product media

System in view

Verified product media appears here when available; clearly labeled placeholders identify what still needs to be supplied.

Verified media pending

POS prototype overview

Supply a desktop floor or kitchen view plus a mobile ordering, guest-join, or split-payment screen.

Portfolio screenshots of the working POS prototype have not been supplied yet; the live demo remains available for review.

Operational problem

Restaurant orders cross staff access, tables, diners, modifiers, pricing, guest requests, kitchen production, payment, and support history. When those states drift, the team must reconcile what was requested, approved, fired, served, and paid during active service.

Intended for

Independent restaurants, pizza shops, bars, food halls, pop-up operators, and growing hospitality concepts that want an owned ordering experience shaped around their service model rather than a generic terminal workflow.

Previous workflow

A small operation may combine handwritten tickets, verbal kitchen calls, generic terminals, separate QR menus, payment hardware, and manager memory, leaving customer context and production status distributed across people and devices.

Solution

A browser-runnable vertical slice that models employee entry, a multi-table floor, custom pizza pricing, guest item proposals with server approval, kitchen lifecycle transitions, equal-split mock payments, configurable voice, and append-only event history.

Key capabilities

Responsive staff floor and table workflow
Custom items with integer-cent pricing
Guest join and employee approval boundary
Kitchen display lifecycle
Equal-split mocked payment authorization
Configurable sarcastic voice with neutral safety contexts
Multi-location PostgreSQL persistence schema
Append-only audit-event model

Technologies / working stack

Next.js 16 App RouterReact 19TypeScriptDrizzle ORMPostgreSQL schemaZodBunTailwind CSS

Intended outcome

The intended outcome is a restaurant system that keeps floor, guest, kitchen, payment, and audit context connected while allowing a memorable brand voice in non-sensitive moments. The current prototype demonstrates the workflow but has not produced verified service-speed, order-accuracy, or revenue results.

Limitations and status

This is an in-progress prototype using in-memory interaction, a seeded development PIN, a decorative same-browser QR flow, mocked kitchen updates, and mocked card authorization. Production persistence, hashed authentication, rotating join tokens, real-time projections, certified payments, refunds, reconciliation, offline recovery, printers, cash drawers, device testing, and security review remain future milestones.

Relevant next step

Does one of these applications resemble your operation?

Start with one current process, the decisions it carries, and the handoffs or exceptions that create the most operating drag.

Discuss a custom POS workflow

Key capabilities

Responsive staff floor and table workflow
Custom items with integer-cent pricing
Guest join and employee approval boundary
Kitchen display lifecycle
Equal-split mocked payment authorization
Configurable sarcastic voice with neutral safety contexts
Multi-location PostgreSQL persistence schema
Append-only audit-event model

Intended outcome

Limitations and status