TadkaOS: running eight brands out of six kitchens without losing track of a single order

On a Friday night in TadkaOS's busiest kitchen, the order counter had six tablets: one per aggregator per brand group, plus the brand's own website orders printed on a thermal printer. Each tablet beeped differently. At peak, an order could sit unaccepted for minutes because the person nearest was busy with another tablet — and missed orders meant cancellations, penalties and ratings that hurt every brand in the kitchen.

Behind the counter, cooks worked from printed tickets that did not show which brand an order belonged to until they read the packaging instructions. Stock ran out mid-service because nobody knew how much of a base gravy eight brands were drawing on.

We spent three evenings in two kitchens, timing orders from arrival to dispatch. The delays clustered at predictable points: accepting the order, figuring out which station needed to start first, and assembling multi-brand orders for the same rider. Ingredient shortages were almost always base preparations shared across brands, which nobody tracked below the level of finished dishes.

TadkaOS pulls orders from every aggregator and the website into one hub that auto-accepts within the kitchen's rules. Each order is broken into station tasks and shown on kitchen display screens, sequenced so that the longest-cooking items start first and everything finishes together.

Recipes are modelled down to base preparations and raw ingredients. Every order depletes inventory at that level, so the kitchen sees, mid-service, that tonight's makhani base will run out in forty minutes — while there is still time to prepare more.

Real-time reliability was critical, so the backend team included an engineer focused solely on aggregator integrations and failover.

These were agreed with the founder and the head chef, whose kitchen it had to work in.

Everything that shipped across the counter, the kitchen and management.

We launched in the busiest kitchen first, on a Tuesday, with our engineers in the kitchen through the first weekend rush. The old tablets stayed switched on for a week as a fallback and were then unplugged. Recipe data was the slowest part of rollout: the head chef and our team weighed and documented base preparations for every dish.

Build for the busiest hour. Every design choice was tested against Friday dinner, not a quiet afternoon.

Model the recipe, not the menu. Tracking base preparations shared across brands was what finally stopped mid-service shortages.