Operations Platform for a Tashkent Cloud Kitchen Group
Designed and built a clickable operations platform for a Tashkent cloud kitchen group running 8 delivery-only brands from 4 dark kitchens: aggregator orders in one queue, one switch that takes a sold-out ingredient off every brand and aggregator, recipes that cost every dish, and the real contribution of each order after commission.
Most of our work is under NDA. Per agreement, we can share the work but not the company details - all names and identifying information shown here have been changed.
Group dashboard, live orders, order detail, availability and recipe detail. Every one of the 28 demo orders and 10 recipes opens its own page.
Turning off lamb shoulder at Chilanzar finds every dish that uses it through sub-recipes and takes 6 menu items across 3 brands off both aggregators, with the push result shown per aggregator.
Recipe costs roll up from ingredient prices, quantities and yield % through sub-recipes, so every menu item and order shows its theoretical food cost against the brand's target.
8 brands in 4 kitchens on 2 aggregators, 18 menu items, 10 recipes, 27 ingredients and 7 items switched off, at a Wednesday lunch peak in Tashkent.
Anhor grew from one brand in one kitchen to 8 brands in 4 kitchens in under three years, and its tools did not grow with it. Each aggregator had its own tablet on the pass, so a sold-out item had to be switched off by hand on every tablet for every brand that used it. Recipes lived in a chef's notebook, temperature checks were on paper sheets, stock was counted in a spreadsheet once a month, purchasing ran on Telegram, and finance could not say which brands made money once 20 to 30 percent commission came off every order.
Qozon connects every brand's menu to one shared set of recipes and ingredients. Aggregator orders arrive in one live queue routed to the right kitchen and station, availability is switched by ingredient across every brand and aggregator at once, every dish is costed from its recipe, and each order shows its commission, fees, payout and contribution.
A cloud kitchen sells the same rice, lamb and flour under several brand names, through aggregators that each take their own commission. Every decision about stock, price or food safety touches many listings at once.
Lamb goes into plov, lagman and a plov bowl sold by three different brands. When it ran out, staff had to find and switch off each item on each aggregator tablet, and customers kept ordering dishes the kitchen could not make.
With recipes in a notebook, nobody knew what a portion of plov cost after the price of rice or mutton moved. Shared bases, trim and cooking losses had to be counted before a food cost percentage meant anything.
Each aggregator charges its own commission and fees, and discounts can be funded by the aggregator or by Anhor. The group could see its total, but not which brands still made money once commission came off every order.
Kitchens of this size are expected to run a HACCP-based food safety system, with every reading and check kept with who did it and when. Paper sheets went missing before inspections, and customer and staff data falls under Uzbekistan's Law on Personal Data.
Mapped 10 user roles, 53 screens (43 staff web screens and 10 kitchen tablet screens) and the data model for brands, aggregator listings, menu items, versioned recipes, ingredients, orders, availability, stock, purchase orders, forecasts, prep lists, HACCP plans and readings, shifts and payouts. Wrote down the rules the design follows: the Law on Personal Data and its 2026 amendments, HACCP records for sanitary inspection, Anhor's temperature limits as settings, 14 declared allergens and prep labels, fiscal receipts with product classification codes, the Labour Code's 40-hour week, and an audit trail of every change.
Built 5 key screens on a production dashboard kit: the group dashboard with 5 KPI cards, the kitchens and brands grid, sales by hour against the forecast, the brand league and needs-attention cards; live orders with accept and reject; order detail with money, cost and fiscal receipt; availability by ingredient and by brand; and recipe detail with yields, sub-recipes, a 90-day cost chart, allergens and critical control points. Costs are computed from the demo recipes and prices, and actions run on local state.
Integration with Yandex Eats and Uzum Tezkor for menu sync, orders, availability and payouts, a licensed virtual cash register, Didox or Faktura.uz e-invoices, 1C:Accounting export, Telegram and Eskiz SMS alerts, wireless temperature probes, label printers and the demand forecast feed. Staff roles scoped by kitchen, a full audit log with before and after values, in-country hosting, and the remaining screens: menus, stock, purchasing, prep, food safety, rota, brand P&L, payouts and the kitchen tablet.
The By ingredient view lists every menu item that uses an ingredient at the chosen kitchen, including through sub-recipes. Turning it off needs a reason and a planned back time, and a push that failed on one aggregator is shown on the item and on the dashboard.
Each ingredient line shows quantity, yield % for trim and cooking loss, current price and its share of the batch cost. Shared bases such as the zirvak are their own sub-recipes, and the Used by list shows each menu item's food cost % at its aggregator price.
The order page separates aggregator-funded and Anhor-funded discounts, applies the commission term in force when the order arrived, deducts fees to the expected payout and sets the theoretical food cost against it, so the contribution of each order is visible.
Orders turn amber when not accepted within 2 minutes and red past pickup time. The dashboard collects items off for over 2 hours, failed pushes, temperature breaches without a corrective action and purchase orders awaiting approval, each linked to where it is fixed.

Designed and built a clickable kitchen display system for a 26-restaurant burger and fried chicken chain in Algeria: every order from the till, kiosks, drive-thru and delivery apps is split into station tickets, timed so the whole order finishes together, paced to the rider and checked at expo before it leaves, with allergy notes that can never be hidden.

Designed and built a clickable ops console for a Kathmandu food delivery platform that links customers, about 600 restaurants and 900 riders: live orders and alerts across three cities, zone modes for surge, rain and road closures, a money split on every order, and weekly rider payouts with a per-order breakdown and two-person approval.
Enterprise Software Engineering - Human + AI
Contact Us
© 2026 - Copyright. All Rights reserved Oceanlab
Location
Global Headquarters
21 Merchant Road, 3rd Floor, Singapore 058267
Main corporate office and leadership operations
North America Office
548 Market Street, PMB 12345, San Francisco, CA 94104
Client operations and business development
India Office
402 Shivalik Shilp II, SG Highway, Ahmedabad 380015
Engineering and delivery center
Enterprise Software Engineering - Human + AI
Contact Us
Locations
Global Headquarters
21 Merchant Road, 3rd Floor, Singapore 058267
Main corporate office and leadership operations
North America Office
548 Market Street, PMB 12345, San Francisco, CA 94104
Client operations and business development
India Office
402 Shivalik Shilp II, SG Highway, Ahmedabad 380015
Engineering and delivery center
© 2026 - Copyright. All Rights reserved Oceanlab