9hwa café operations platform

Problem

Small cafés need one operational model where a sale, its ingredient consumption, its cost, and the staff action stay consistent.

My role

Sole developer; domain model, application architecture, database security, UI, and tests

Stack

Next.js 16
TypeScript
Supabase
PostgreSQL
RLS
PGlite
Playwright

How the work moves

Step 01Mobile saleStaff order and payment
Step 02TransactionSale + recipe consumption
Step 03Stock ledgerImmutable movement history
Step 04OperationsAlerts, margins, inventory

The business problem

A café sale changes more than a revenue total. It consumes several ingredients in different units, affects stock alerts, belongs to a staff shift, may print a receipt, and must remain explainable during an inventory count.

Architecture decisions

The domain model treats stock as a ledger rather than an editable number. PostgreSQL functions record each movement and update the current balance in the same transaction. Recipe units convert only within compatible dimensions, and insufficient stock cancels the complete sale.

A workspace-level lock serializes mutations. That is deliberately simple for a café-sized workload; a higher-volume system would need finer-grained locking, and the project documentation says so.

Security and verification

RLS, composite foreign keys, and role checks isolate establishments. Staff receive only their permitted catalog, order, and shift data; cost and global statistics stay out of their response entirely. A deactivated account loses data access even if its browser session still exists.

PGlite tests apply the real migrations and exercise transactional functions, roles, and isolation across two establishments. Browser scenarios cover critical operating flows, and the README keeps those checks separate from a real Supabase deployment test.

Status

9hwa is a prototype with a working local demo and a Supabase-ready production path. It has not been deployed publicly yet.