Five order types, one weekly job.
Roughly 65 subscribers, about 600 meals a week, and a Monday morning that used to cost somebody four to five hours. Live since March 2026, still running now.
This is a real system. I've left out the client's name and anything confidential in the video is pixelated. Nothing else is changed. Every number here is exactly as it runs.
Loading walkthrough
Embed not loading? Watch it on Loom.
You can run a version of this yourself. I rebuilt the compile logic against invented orders, so you can hit run, see what it holds back for review, fix those rows and watch the reports rebuild.
Try the compilerFive ways an order could arrive
Some customers picked their own meals for the week. Some were on a plan where the chef picked instead. Some bought individual meals off the site, one at a time. There was a VIP group where a nutritionist emailed over a spreadsheet with the meals already worked out. And on top of that, a breakfast subscription that renewed itself every week with nobody touching it.
All five landed at once, every Monday morning. Somebody then had to turn them into two things, a cooking list and a shipping list. That meant reading through spreadsheets, checking who had actually paid, who was paused, and working out which day each box needed to go out. Four to five hours, every single week, rebuilt from scratch by whoever had time.
And some of those orders carry allergy and dietary information. Get one wrong and somebody eats something they shouldn't.
Five inputs in, four outputs out
The system reads about 5,000 records every Monday morning. Orders, customer profiles, delivery details, plan data, all of it. That becomes one clean sheet of roughly 500 rows, one row per meal. From there it generates the prep list of what to cook and how much, a shipping summary of who gets what and which day, structured records in Google Sheets, and a print-ready PDF for every customer's box.
What this one is built with
Wix Velo, JavaScript, Google Sheets, Google Apps Script, the site's own APIs, webhooks, Excel parsing for the nutritionist's spreadsheets, a PDF library, and a custom backend tying it together.
I used AI help while building it, to be clear about that. The logic, meaning what should happen when the input doesn't cooperate, was mine to work out and test against real orders.
This one needed custom code because of how the orders arrived. Plenty of jobs don't.
Three decisions under the hood
The system only trusts live subscription and order data straight from the website when it decides whether somebody's meals are good to go that week. Active, paid, everything filled in. Older or backup records get used for identity and delivery history, never on their own to decide what gets cooked. That rule wasn't there in the first version. I added it after an old backup record let a wrong row slip into production.
Every week the run does a full test pass first, a dry run into separate tabs, checked against real customer counts, new signups and any tricky plan types I already know about. Only once that looks right does the same job run 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. A matching layer maps those Japanese plan names to the right category before anything else runs, so a plan never quietly fails to match because of the language somebody picked it in.
It holds back what it can't verify
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 can't read, the system doesn't guess. It sets that order aside in a queue for a person to check before anything gets cooked.
That was a deliberate call. Guessing would have meant less manual checking and more automation. It also would have meant a wrong guess could reach somebody's kitchen. On a system carrying allergy and dietary information, that isn't a risk worth saving twenty minutes for.
Four to five hours, now about thirty minutes
That's the full weekly job. Matching every order source, building the cook list and shipping list, generating all the PDFs, and reviewing and fixing anything the system held back.
It didn't start clean. There were processing errors in the first few weeks while it settled, a parsing issue here, a formatting mismatch there. After that, nothing. The engagement ended in late June and I wrote the full handover doc before I left, covering the weekly workflow and the troubleshooting steps their own team would need to run it without me. It still does.
The bug that would have cost them money quietly
Early on, the Sheets side added a new row every time the weekly job ran. So if I ran it again for any reason, a fix, a retest, whatever, a customer's order could show up twice in the cooking count. Nobody notices one extra portion of pasta until the kitchen has been overcooking for weeks and nobody knows why.
I changed it to overwrite in place. Every run now 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.
Muhammad Arsal Murad built and handed over this system. If you have a Monday morning that looks anything like this one, book twenty minutes and we'll work out whether it's fixable.