Case study
4 to 5 hours a week.
Now it's about 30 minutes.
So this is the order to kitchen system I built for a subscription meal kitchen in Japan. It's got roughly 65 subscribers, does about 600 meals a week, and it's been live since March 2026. Still running today too.
This is a real system and it's still running today. I've left out the client's name, and anything confidential in the video is pixelated. Nothing else is changed. All the numbers and everything about how it works is exactly as it runs.
Loading video
You can run a version of this yourself. I rebuilt the compile logic with fake orders so you can hit run, see what it holds back for review, fix those rows, and watch the kitchen reports rebuild.
Try the compilerThe problem
Orders for this kitchen come in five different ways, which honestly is a lot. Some customers just pick their own meals for the week. Some are on a plan where the chef picks for them instead. Some just buy individual meals off the site, one at a time. Then there's a VIP group, where basically a nutritionist emails over a spreadsheet with their meals already worked out. And on top of all that there's a breakfast subscription that just renews itself every week, nobody has to touch it. All of it lands at once, every Monday morning.
Before I built this, someone had to sit down every single week and turn all five of those into just two things, a cooking list and a shipping list. That took four to five hours, every time. Basically reading through spreadsheets, checking who actually paid, who was paused, and figuring out which day each box needed to go out.
Five different order sources had to turn into one simple answer, what to cook and where it goes. That path just didn't exist before. Every week someone rebuilt it from scratch, by hand, whoever had time that day. And some of these orders have allergy and dietary info attached too. Get one wrong and someone could actually eat something they're not supposed to.
What I built
I built the system that takes all five of those input types and turns them into what the kitchen actually needs. It pulls in something like 5,000 records every Monday morning, orders, customer profiles, delivery info, plan data, all of it, and turns that into one clean sheet of about 500 rows, one row per meal. From there it generates a prep list, what to cook and how much, a shipping summary, who gets what and which day, structured records in Google Sheets, and a print ready PDF for every single customer's box.
What this one's built with: Wix Velo, JavaScript, Google Sheets, Google Apps Script, website APIs, webhooks, Excel parsing for the nutritionist's spreadsheets, a PDF tool, and a custom backend tying it all together.
I did use AI help while building it, just to be clear. But the actual logic, like what should happen when the input doesn't cooperate, that part was on me to figure out and test against real orders.
This one needed custom code because of how the orders came in. Plenty of jobs don't. I work in n8n, Make.com and Zapier too, and if your stack is already sitting on one of those, that's usually where I'd start.
Under the hood
The system only trusts the live subscription and order data straight from the website when it's deciding if someone's meals are good to go that week. Meaning active, paid, and everything filled in. Older or backup records just get used for stuff like identity and delivery history, never on their own to decide what actually gets cooked. That rule wasn't there in the first version honestly. I added it after an old backup record caused a wrong row to slip into production one time.
Every week the run goes through a full test pass first. Basically a dry run into separate tabs, where I check it against real customer counts, new signups, and any tricky plan types I already know about. Only after that looks right does the same job run again for real, against the live sheet.
Some customers manage their plans in Japanese, and the label they see on the site doesn't always match what the system expects internally. There's a matching layer that maps those Japanese plan names to the right category before anything else even runs. That way a plan doesn't just quietly fail to match, just because of the language someone picked it in.
The decision that mattered most
When something isn't clean, like no delivery day picked at checkout, a payment that failed, a subscription that's paused, or a spreadsheet cell the parser just can't read, it doesn't guess. It just sets that order aside in a queue for a real person to check before anything gets cooked.
I made that call on purpose, honestly. Guessing would have meant less manual checking and more automation, sure. But it also would have meant a wrong guess could actually reach someone's kitchen. And on a system carrying allergy and dietary info, that's just not a risk worth saving a bit of time.
Results
The full weekly job, matching up every order source, building the cook list and shipping list, making all the PDFs, dropped from 4 to 5 person hours down to about 30 minutes. That's including time to review and fix anything.
It honestly didn't start out clean though. There were some processing errors the first few weeks while it settled in, like a parsing thing here, a formatting mismatch there. After that, nothing. The engagement itself ended in late June, and I wrote the full handover doc before I left, the weekly workflow, the troubleshooting steps, everything their own team would need to run it without me. It still does.
What I'd change
So early on, the Sheets side of this just added a new row every single time the weekly job ran. Which meant if I ran it again for any reason, like a fix, a retest, whatever, a customer's order could show up twice in the cooking count. And honestly, nobody notices one extra portion of pasta until the kitchen's been overcooking for weeks and nobody knows why.
I changed it to overwrite in place instead. Now every run replaces that week's rows instead of piling on top of them, so a re-run is always safe no matter why I'm running it.
Get in touch
If you run an agency and work is piling up
I take on subcontracted builds when your own team is too booked up. n8n, Make.com, Zapier, or custom code if the job needs it. You stay the main contact with the client, I just build to the spec and hand back something that actually works.