Giving a 600-person food group a spine

A fast-growing quick-service food group with its own manufacturing: 32 branches, one head office, one factory, two warehouses — a central warehouse and a central kitchen — and over 600 employees. Traffic runs about 7,000 orders on weekdays and 20,000 on weekends, concentrated in a tight burst from 7 PM to 1 AM.

Young founders who scaled up together from the start, with the business racing ahead of its own systems — the way fast-growing companies do.

Foodics is a real-time firehose — at peak, 20,000 orders crash in inside a six-hour window. Odoo is a monolith: every order fans out into synchronous writes — order, lines, picking, stock moves, journal entries — each carrying business logic, computed fields and table locks. Under a concentrated real-time burst, that write path is the wall.

And here’s what most teams get wrong: no amount of infrastructure fixes it. Bigger servers, more memory, more workers — the system still breaks, because the bottleneck isn’t hardware, it’s architecture.

The business ran on spreadsheets and sharp instinct — and it worked, right up until the volume outgrew it. A dedicated team spent its days hand-building inventory, cashflow and reporting spreadsheets. Foodics and Odoo disagreed on basic facts — different working days, thin documentation, reports that were only sometimes accurate.

And despite thousands of orders a day, cashflow was strained, because nobody could see the numbers in time to act on them. Like most fast-scaling operations, the processes lived in people’s heads, not in documents. There was no spec to implement — it had to be designed first, together.

There was no spec to hand me, so I built the understanding myself: diagnose how the operation actually ran, surface the handoffs and exceptions that lived only in people’s heads, design the process with them, then connect every part into one system. My value wasn’t specialist depth in one corner — it was seeing the whole board: how an order at 2 AM has to flow into stock in kilos, cost from a gram-level recipe, a shift-dated P&L, a multi-level approval and a weekly reconciliation — and making all of it agree.

The sharpest call was the first: this was an architecture problem wearing an infrastructure costume. Rather than scale hardware into a wall, I re-architected around the monolith’s limits.

One real-time source of truth across 32 branches, the factory, the warehouses and head office — Foodics, inventory, manufacturing, accounting and HR finally agreeing. The manual, spreadsheet-driven reporting was replaced by trustworthy real-time reports, so the business could finally see its numbers in time to act on them — the visibility needed to attack the cashflow problem at its root.

Branches keep selling through stockouts, the factory has full traceability, and approvals happen in the system, not in chat threads.