Arsal MuradWorkflow automation
← Back to the case study
Interactive demo

Run the compiler yourself.

This is a working, stripped down version of the weekly order compiler I built for a subscription kitchen. Same routing rules, same review queue, same reports. Hit run, then deal with whatever it holds back.

Every customer, meal and plan on this page is invented for the demo. No client data is used here. The real system runs on a private site and I can't show that, so this rebuilds the logic against fake orders instead.

Incoming orders this week

11 records across 5 sources
3Customer picked
3Chef picked
2One off orders
2Nutritionist upload
1Auto renewing

Some of these are clean. Some are missing a delivery day, or the payment didn't go through, or the plan name came in Japanese. That's a normal week.

What you're actually looking at

The interesting part isn't the reports, it's what the compiler refuses to do. Anything with a missing delivery day, a failed payment, a paused subscription, or a nutritionist sheet it can't fully read gets held back instead of guessed at. On a kitchen where some boxes carry allergy information, a confident wrong answer is worse than no answer.

The rest is bookkeeping that used to eat four to five hours a week. Plan names arriving in Japanese get matched to the right category before anything runs. A 14 meal plan expands to double the 7 meal list. Deliveries get grouped into early and late week so the kitchen isn't cooking Saturday food on Monday.

This particular build needed custom code. A lot of work doesn't, and I'll happily build the same kind of thing in n8n, Make.com or Zapier if that's what you're already running. The judgment about what to automate and what to leave for a person is the same either way.

Or book a time directly →