The server prices the order
The API refetches menu items and calculates totals. Prices sent by the browser are never authoritative.
Flagship / Engineering case study
Bite Relay
From a table QR code to payment to a physical kitchen printer.
Live · ProductionVisit project ↗
TypeScript / Next.js / Fastify / Node.js / PostgreSQL / Supabase / Prisma / Stripe Connect / Vercel / Railway
Cloud / trusted payment event
Stripe webhook → paid → jobs
The browser cannot declare an order paid. Print jobs, KDS and notifications start at this transition.
Venue LAN / outbound polling
Bridge → queue → printer
The local Node process asks the cloud for work. No inbound route through venue NAT is needed.
01 / The problem
The problem
An order has to travel from a guest’s phone to payment, kitchen and bar without trusting browser prices or losing the connection to physical venue hardware.
02 / What I built
What I built
A multi-tenant hospitality platform with four runtime targets: customer Next.js app, admin Next.js app, Fastify API and an on-site Node print bridge. Guests scan, browse, order and pay on their phones. Stripe Connect settles payments directly to the venue; the platform holds neither venue funds nor raw card data.
03 / Architecture
Architecture
- Guest → customer Next.js app (Vercel)
- Fastify API (Railway) → server-priced order
- Stripe Connect → verified payment webhook
- PostgreSQL / Supabase → print jobs, KDS, notifications
- Venue LAN → Node bridge polls outward → kitchen / bar printer
- Admin Next.js app (Vercel) → guarded venue operations
04 / Key decisions
Key decisions
One choke point for payment side effects
Only the Stripe webhook can mark an order paid and trigger printing, KDS tickets and notifications. Keeping this transition in one place makes webhook replay and idempotency manageable.
Let the venue connect outward
Printers sit behind private LANs and NAT. The local bridge polls for queued jobs, avoiding inbound configuration and persistent-connection state. Jobs can resume after temporary outages.
Close independent bypass paths
Central access decisions and route guards protect the API. Supabase Row Level Security closes a different path through its generated API. Per-printer credentials replace a shared platform-wide bridge secret.
05 / What went wrong
What went wrong
Permissions on screen were not permissions on the server
- Problem
- A valid manager session could reach operations outside its intended venue or permissions.
- Why it happened
- The UI displayed roles, but meaningful server-side enforcement was missing.
- How it was detected
- A multi-tenant authorization audit exercised routes directly and tested cross-venue access.
- Response
- Centralized authorization and route-level guards were introduced and tested against cross-venue cases. The Revision 3 fixes were committed, pushed, deployed and verified in production.
- Lesson
- A hidden button does not constrain a caller. Test the server independently of the interface.
06 / Evidence
Evidence
- Four distinct runtime targets across cloud and venue hardware.
- Production verification of the Revision 3 audit fixes.
- Supporting audit work covered webhook replay, stored HTML injection, uploaded file signatures, printer status and production configuration.
Bite Relay / existing project capture
07 / Current status & limitations
Current status & limitations
Live · ProductionLive production system. CI and staging, some security/audit work, dependency upgrades and complete E2E coverage remain areas to improve. Production verification is not a claim that every possible failure is covered.
Evidence basis: project implementation review and research notes supplied for this portfolio, September 2026. Project tests described here are distinct from the portfolio’s own checks.