Concept demo · Family business
Order System Sandbox
Meal-Prep Studio Order System
One day at my mum's meal-prep studio, from the evening sign-up to the last delivery, played out on made-up members so you can try it yourself.
The real app has been in production since April 2026
This is a concept illustration, not the real system. The real app and its code are private because they hold real customer data. Everything on this page is synthetic: the members, meal counts, prices and chat messages are made up, and nothing you do here leaves your browser.
The problem
My mum runs a small meal-prep studio. Members buy a prepaid meal card, then sign up for the next day's lunch and dinner in a group chat.
Before this system, each evening's sign-ups were tallied by hand and passed along by message. The day's orders, card balances, income and spending were then keyed into an Excel workbook, so the same numbers were handled more than once before the day was closed.
What it does
The app follows the studio's day instead of asking the studio to change. Each step is recorded once, when it happens, by the person who does it.
Cards
Staff sell, renew or upgrade a member's prepaid meal card. Each card sale goes into the ledger by itself.
Orders
The evening sign-up becomes the next day's orders, one at a time or as a batch. Lunch and dinner are separate orders, and each meal comes off the member's card.
Kitchen
A phone view moves every meal from pending to prepared to delivered. Delivered is final, so a finished order cannot be quietly changed later.
Finance
Card sales and walk-in meals post to the ledger automatically and spending is entered by hand, so the day's numbers add up without being typed a second time.
How it is built
- Role
- Sole developer
- Started
- April 2026
- Platforms
- Web, plus iOS and Android test builds
- Status
- In production
- TypeScript
- Expo
- React Native
- Hono
- Turso (libSQL)
- Drizzle ORM
- Zod
- Vitest
- Turborepo
- Vercel
- GitHub Actions
One Expo codebase builds the app for iOS, Android and the web. It talks to a Hono API on Vercel, with Turso (libSQL) as the database and Drizzle for the schema and migrations.
The rules live in a shared package of Zod schemas that the app and the API both use, so a form and the server cannot disagree about what a valid order or expense looks like. The sandbox below copies a few of those rules in plain JavaScript.
Anything that touches a card balance and the books together, such as cancelling an order, runs in one database transaction. Card balances and the ledger cannot drift apart that way.
My role
I am the sole developer. I designed the data model and the rules, and built the app, the API and the shared package that holds the rules.
I planned the work in phases tracked in Linear. Work started on 22 April 2026, and sign-in, members, cards, ordering and the kitchen view were live by 25 April. Later releases added retail sales, label printing and a full interface redesign.
Try the sandbox
This is a concept illustration, not the real system. The real app and its code are private because they hold real customer data. Everything on this page is synthetic: the members, meal counts, prices and chat messages are made up, and nothing you do here leaves your browser.
Work through the studio's day in four steps. Top up a card, enter tomorrow's sign-up from the mock group chat, move the meals through the kitchen, then check the day's roll-up. Every action lands in the activity log, the way the real app keeps an audit record.
Synthetic data · Concept illustration, not the real system
Step 1: Top up a card
Members and meals left
- Ava6 left
- Ben3 left
- Coco1 left
- Dev12 left
- ElleUsed up
- Finn9 left
Step 2: Turn the sign-up into orders
Studio group chat (mock)
Studio
Sign-up for tomorrow. Add your name, then L for lunch and D for dinner with how many, like Ava L1 D1.
Edit the list to test the rules. Write (walk-in) after a name for a guest without a card. Each line carries a key, so entering the same line twice never doubles an order.
Check before entering
- Ready1. Ava L1 D1Ava · Lunch 1, Dinner 1 · card 6 to 4
- Ready2. Ben L2Ben · Lunch 2 · card 3 to 1
- Held back3. Coco L1 D1Coco has 1 meal left and this needs 2 meals. Top up first.
- Ready4. Dev D1Dev · Dinner 1 · card 12 to 11
- Held back5. Elle L1Elle has 0 meals left and this needs 1 meal. Top up first.
- Ready6. Sam (walk-in) L1Sam · Lunch 1 · walk-in, $16.00 at $16.00 a meal
Step 3: Kitchen tally
| Status | Lunch | Dinner |
|---|---|---|
| Pending | 0 | 0 |
| Prepared | 0 | 0 |
| Delivered | 0 | 0 |
Orders
No orders yet. Enter the sign-up in step 2.
Step 4: The day's roll-up
- Net for the day
- -$86.40
- Card sales
- $0.00
- Walk-in meals
- $0.00
- Spending
- $86.40
- Meals delivered
- 0 meals
- Meals still on cards
- 31 meals
Ledger
- Groceries for tomorrowmanual-$86.40
Activity log
Newest first. The real app keeps an audit record of every change.
Nothing yet. Try a step above.
What the sandbox leaves out
The sandbox skips sign-in, staff accounts, card upgrades, retail sales and label printing. In the real app, staff enter the sign-up through a batch order form, and an automatic next-day sign-up summary is still on the list. Here the demo reads the mock chat for you so you can see the rest of the loop.
The members, meal packs, prices and spending are invented and say nothing about the studio or the people who use it.
A concept demo with synthetic data. The real app and its code stay private.