Order & subscribe
Pick a joint, browse the live menu, place and track orders, manage meal subscriptions. /order
Operational OS
The system that keeps the promise.
A move-in customer only trusts the second week if the first one is boringly reliable. The operational layer exists to make “dinner is handled” true every single day — and it is already built as a working, login-scoped app.
Live product
Three logins, one backbone
Each Eating Joint runs on the same system, isolated by login so a joint only ever sees its own orders, kitchen, and stock.
Order lifecycle
Every order, one predictable path
1. Placed
Consumer orders from a joint; the order appears live on that joint's board.
2. Accepted → Preparing
The kitchen moves it through prep; producing a batch decrements ingredient stock automatically.
3. Out for delivery
A delivery is created and a rider assigned; the customer tracks status.
4. Delivered → Feedback
Delivery closes the loop; feedback feeds recovery and the extension offer.
Kitchen & inventory, per joint
- Prep batches plan production; marking one produced draws down ingredient stock via recipes.
- Inventory tracks on-hand vs. reorder level, with low-stock alerts and a movement log.
- Purchase orders to suppliers restock ingredients on receipt — a closed inventory loop.
Guardrails that protect trust
- A fixed daily subscriber cap keeps every route and kitchen honest.
- Row-level security isolates each joint's data — a login never sees another joint's orders or stock.
- Concierge + visible recovery when something slips, before the customer has to chase it.
Next
See the economics
How the operational cap and margins add up under the pilot.
Why
The principles behind it
The rules that decide what we build — and what we refuse to.