Changing a menu across 100 venues shouldn't take a week

In most multi-site hospitality operators, the project plan for "update the spring menu across the estate" runs to four pages and three weeks.

Week one is the menu engineering tool: costing, allergen verification, photography, executive chef sign-off. Week two is the rollout coordination: emails to general managers, training sheets to kitchen brigades, FAQ documents to floor staff. Week three is the actual technical deployment: exporting the new menu from the menu engineering tool, uploading to the EPOS vendor's portal, pushing to each individual till, updating the website CMS separately, syncing to the online ordering platform separately again, ensuring the in-room dining tablets get the same menu version, and finally crossing fingers that the QR ordering screens in the beer gardens are pointed at the right menu file.

During the rollout, different tills in the same venue may be showing different menu versions for hours. The website might be showing prices that don't match the till. The online ordering channel might be promoting dishes the kitchen has already removed. The in-room tablet might still be on last season's menu because nobody knew it needed updating separately.

This isn't an exaggeration. This is the operational reality at every multi-site hospitality group running a legacy stack. The Food and Beverage Director has accepted it as the cost of doing business. The IT team has stopped getting excited about menu rollouts. The customer service team has scripts for handling the inevitable "but the website said £14" complaints.

This article is about why it doesn't have to be like this, and what the architecture looks like when it isn't.

The architectural reason menu rollouts are slow

The slowness has one underlying cause: in most stacks, the menu is duplicated across every system that needs to know about it. The EPOS has its copy. The CMS has its copy. The online ordering platform has its copy. The in-room tablet has its copy. The QR ordering screen has its copy. The menu engineering tool has its copy. Each copy lives in a different database with a different schema, owned by a different vendor.

When the menu changes, every copy has to be updated. Each update is a separate operation. Each operation has its own failure modes. The integration layer that's supposed to keep them in sync exists only partially, runs on its own latency budget, and silently fails in ways that show up as customer complaints two days later.

The reason this architecture exists is historical. Each system was bought separately, at a different time, for a different reason. The menu engineering tool was the latest acquisition. The EPOS was a 2018 procurement decision. The CMS predates that. Each vendor has built their own menu model because they had to. Their product needs a menu structure to function, and none of them could rely on another vendor's structure being available.

So every operator running a fragmented stack ends up with five or six "menus" that all describe the same dishes. And every operator has built a workflow (formal or informal) to keep those five or six menus in sync. And every operator has accepted that the sync will sometimes fail.

What changes when there's one canonical menu

The mDOS architecture takes a different position. There's one menu. It's held once for the whole company, with its categories and dishes alongside it. Each venue is simply assigned to it: not a copy of the menu, just an assignment, with an optional set of overrides for venue-specific differences.

This is a fundamentally different data model. There's no duplication. The website, the EPOS, the in-room tablet, the QR screen, and the online ordering channel all read from the same dish records. A change to a dish needs no per-surface sync, because there's only one copy.

Because every surface reads from that single source, a menu edit is reflected wherever the menu is next resolved (a page load, a terminal's menu fetch). There's no copy to push out or reconcile across vendors. For the one change that must land mid-service without waiting for a refetch (86'ing a dish that has just run out), a live broadcast channel pushes the change to every connected surface live (see the 86'ing section below).

Measured latency from the operator clicking "Save" in the menu builder to the change being live on every connected surface across the estate: approximately 200 milliseconds at the 95th percentile.

This isn't a theoretical figure. A single database write, fanned out via one WebSocket channel, results in every till in every venue showing the new state within half a second. There's no version skew window. There's no per-terminal upload step. There's no waiting.

The override system that makes it work at estate scale

A naive "one menu" architecture would force every venue to be identical. The country house hotel with the £180 tasting menu and the city centre wine bar with the £14 small plates would have to be on completely separate menus, which defeats the centralisation benefit.

mDOS solves this through the override system. The base menu is defined once at company scope. Each venue's assignment carries a small set of overrides that can change any field on any item: price, name, description, availability, allergens, dietary tags, calories, image, drink type, ABV, room service availability, room service price, modifier groups, modifier option pricing, category placement, time window availability, or entire category visibility.

The resolver runs purely client-side after the menu has loaded. The resolution cascade is base → group → venue, with the venue's override winning at each field level. The override set is typically under 1KB per venue. The resolution latency is sub-millisecond.

What this means operationally: a 50-venue group can have one "spring menu" definition with 50 venue-specific override sets that handle local pricing, regional ingredient swaps, location-specific availability windows, and venue-specific photography. A change to the base menu (say, removing a dish that's been discontinued) propagates to all 50 venues instantly. A change to one venue's override (say, raising the price on the steak at the London venue) affects only that venue without touching the base.

The legacy alternative is 50 separate menu files, each manually maintained, each requiring its own update when the base changes. The drift between them is inevitable. The administrative load is significant. The opportunity for error is constant.

The Natasha's Law publish gate

In the UK, the Food Information Regulation (commonly called Natasha's Law) requires hospitality operators to provide full allergen information for any food prepared on the premises and packaged for sale. Violations carry significant regulatory penalties and, in extreme cases, criminal liability.

Most hospitality menu systems handle allergen compliance in application code. The menu builder displays a warning if allergens are missing. The publish workflow checks for completeness. The training material reminds staff to verify allergens before publication. All of this can be bypassed by a determined or distracted operator.

mDOS handles it at the database layer. Every menu item carries an allergen status. Items still awaiting verification can't be published: a database rule on the menu publish operation stops the publish if any unverified item is included. Verification requires explicit action: a logged-in user with the appropriate role marks the item as verified, and the database records who verified it and when for the audit trail.

This isn't a UX choice. It's an architectural choice. The database refuses to publish unverified items, regardless of which interface is attempting the publish, regardless of which user is doing it, regardless of what application code thinks is acceptable. The compliance gate can't be bypassed because it's enforced at the layer beneath the application.

For multi-site operators, this matters at audit time. Regulatory reviewers can be shown the gate at the database level. Not a policy document, not a training certificate, but the literal database rule that prevents non-compliant publishes. The compliance posture moves from procedural to architectural.

Real-time 86'ing: the operational moment of truth

Menu rollouts are the planned scenario. The unplanned scenario (and the one that matters most operationally) is mid-service 86'ing. The kitchen runs out of an ingredient. The dish needs to come off the menu now. Every surface needs to stop selling it immediately.

In a fragmented stack, this is a manual process. The chef tells the floor manager. The floor manager walks to each till and updates it. The website remains live with the dish for whatever time it takes someone to remember to update it. The online ordering channel keeps taking orders the kitchen can't fulfil. The QR screens in the beer garden keep showing it.

mDOS handles 86'ing as a single toggle. The floor manager taps "Unavailable" on the dish in the menu management interface. The update marks the dish as unavailable with a timestamp, and a live broadcast channel for your company pushes the change to every connected surface near-instantly: every till stops showing the dish, every QR screen greys it out, every online ordering interface marks it sold out, every in-room tablet hides it.

The kitchen never receives another order for the 86'd dish. The chef doesn't have to apologise to the next table. The waiter doesn't have to walk an embarrassed return back to the kitchen. The guest never gets the disappointment of ordering something that can't be served.

For high-velocity venues (busy Friday evenings, full house dining services, peak rush at a tourist destination), this matters enormously. Every minute of latency between "86'd" and "actually 86'd everywhere" is a minute of accumulating problems. mDOS reduces that latency to half a second.

What this means for the F&B director

For the Food and Beverage Director of a multi-site group, the menu management problem has been one of the most operationally frustrating constraints on their role. The technical reality has limited what they can do. Seasonal menu refreshes are quarterly events that take three weeks to roll out. Mid-season tweaks are politically expensive. They require coordinating with IT, with ops, with marketing, with the brand team. By the time the tweak ships, the moment has passed.

In a unified architecture, the F&B Director can ship menu changes the way they actually want to. Spring menu drops on Monday morning across all 200 venues simultaneously. Mid-week tweak based on early sales data ships Wednesday afternoon. Limited-time promotion launches Friday with venue-level overrides for regional pricing. The technology stops being the rate-limiter on what the F&B function can do.

For acquirers evaluating mDOS as IP, the architectural soundness of the menu management subsystem is a quiet signal. Most hospitality SaaS treats menu management as a peripheral feature: a basic editing screen over a vendor's menu table, with limited propagation logic. mDOS treats it as a core subsystem with the same rigour as the payment engine: canonical single-source data model, atomic operations, broadcast-based 86 fan-out, compliance gates at the database layer. The engineering depth here predicts the engineering depth elsewhere.

---

The menu management subsystem handles base + override resolution, broadcast-based 86 fan-out, and Natasha's Law allergen verification gating. Technical documentation available under mutual NDA.