Food businesses run on windows measured in minutes, and they will abandon software that does not respect them.
This is the sector where technically correct systems fail most often on adoption. If a kitchen display takes two seconds to update during a lunch rush, the staff stop trusting it, revert to printed tickets within a week, and the project is dead regardless of how well the data model was designed. Responsiveness is not a performance goal here. It is a functional requirement.
What we build
- Ordering platforms. Web and mobile ordering with menu and modifier modelling that survives contact with how kitchens actually work.
- Kitchen display and workflow. Order routing across stations, preparation timing, and the sequencing that gets a whole table’s food ready together.
- Delivery dispatch. Courier assignment, batching, live tracking and delivery estimates that hold up.
- Multi-site operations. Central menu and pricing management, per-site availability, stock depletion and reporting across an estate.
- Integration with what is already there. EPOS systems, payment terminals, aggregator platforms and accounting.
What determines whether it gets used
Menu modelling is the foundation
Sizes, modifiers, nested modifiers, combos, allergens, per-channel pricing, time-limited availability, and items that are only available as part of something else.
Get this wrong and every downstream feature fights it. A modifier model that cannot express “large pizza, half one topping half another, no cheese on one half” will produce workarounds that corrupt reporting, confuse the kitchen and eventually require the schema change everyone was avoiding.
It is worth spending disproportionate time here before building anything else, because practically every other feature reads from it.
Real-time means sub-second
Orders must appear on kitchen screens immediately. Not after a poll interval, not after a retry. Anything that reads as a delay erodes trust, and trust determines whether the system is used at all once service gets busy.
This usually means a persistent connection to kitchen displays rather than polling, with the reconnection behaviour thought through rather than assumed.
It has to fail gracefully
Connectivity in kitchens is unreliable, between the steam, the distance from the router and the cheap hardware. Displays should queue locally and reconcile on reconnect rather than blocking service. A kitchen that cannot see orders because the network dropped is a kitchen that stops serving.
The same applies to payment terminals and to any dependency on an aggregator’s API. Degraded operation must be a designed state, not a crash.
Estimates should be honest
Delivery times that are consistently optimistic generate more support cost than they save in conversion. Customers who were told twenty minutes and waited forty do not order again, and they do call.
Realistic estimates need actual preparation times per item, current kitchen load, and courier availability, not a fixed number chosen because it looked good in a mockup.
Aggregators are a channel, not an afterthought
Most food businesses sell through their own channel and through one or more aggregators simultaneously, each with different commission, different menu constraints and different requirements for order acknowledgement.
Stock and availability are shared across all of them. Marking an item unavailable needs to propagate everywhere within seconds, or the kitchen receives orders it cannot fulfil, which costs a refund, a rating and often a customer.
Operational reality
Two constraints shape the work more than any technical consideration.
The people using this are busy. Interfaces designed for a calm evaluation will fail during service. Large touch targets, obvious state, minimal navigation depth, and no confirmation dialogs on frequent actions. If it takes more than a glance to read, it will not be read.
Turnover is high. Staff training time is short, and a system requiring more than a few minutes to learn will be used incorrectly. This is a strong argument against configurability in the front-of-house interface, even where the business wants it. Put flexibility in the back-office, not in the hands of someone taking an order at peak.
What we would ask you first
How many sites, and how much menu variation between them; which aggregators you sell through; what your EPOS is and whether it has an API; what happens today when an item runs out; and what your current ordering process does when the internet drops.
Then we would want to watch a service. Twenty minutes in a kitchen during a rush tells you more about the requirements than a week of workshops.