Dieture Operations Platform

An operation spanning a kitchen, a packing line, a delivery fleet and a support desk produces the same information four times, in four places. Before the platform, each of those ran on its own tool — spreadsheets, chat threads, printed sheets — and none of them agreed with the others.

The cost shows up as questions nobody can answer quickly: where is this subscription in today's cycle, why did this delivery miss, how much of this ingredient does tomorrow need. Past 10,000 active customers, the gaps between tools stopped being an annoyance and became the constraint on growth.

One microservices backend holds the domain — subscriptions, customers, menus, inventory, deliveries — and every surface above it is a thin, role-specific client over that single model. No business rule gets re-implemented in an app.

Each field app is deliberately narrow. A chef mid-service, a packer at the line and a driver holding a phone in one hand do not need the same screen, and none of them needs a general-purpose one. Each app answers the single question its user has at that moment.

• Kitchen app — production requirements per service, derived from live subscription data into what actually has to be cooked
• Packer app — the packing line's queue, item by item, with verification built into the flow
• Driver app — the day's route and stops, built for one-handed use in a vehicle
• Backoffice dashboard — the control surface over all of it

The dashboard replaced the most tools. It is a custom ERP and CRM in one: subscriptions with their full history, customer progress, deliveries, packing, kitchen workflows, B2B retailer accounts, and internal capture of complaints and feedback — plus the configuration that drives every other app in the platform.

Two parts took the most work. Delivery coverage is modelled as editable geographic zones rather than a list of accepted areas, so operations can redraw what is serviceable without a developer. And every meaningful action writes a structured log entry, which is what turned "why did this happen" from an investigation into a query.

• Custom delivery-coverage mapping, editable by the operations team
• Subscription lifecycle — pauses, plan changes, renewals and full customer history on one timeline
• B2B retailer accounts alongside direct consumer subscriptions
• Advanced theming and configuration, propagated out to the field apps
• Detailed structured logging and real-time operational insight

I contributed heavily to the backend and owned large parts of the dashboard across three years — the complicated features rather than the screens: coverage mapping, the configuration layer, subscription state handling, and the logging that made everything else debuggable.

Building where a bug has a physical consequence changes how you work. A wrong number in the kitchen app is wasted food; a wrong route is a customer who does not eat that day. That is the discipline this codebase taught me.