# The Menu Modifier Problem — Modelling Restaurant Data Properly *Modifier groups, selection rules, versioning and channel pricing — why restaurant menu modelling breaks POS systems and how to design it correctly.* By [techcirkle](https://paragraph.com/@techcirkle), 2026-09-02 data modeling, restaurant technology, datamodeling, architecture, saas, backend --- ![Restaurant point of sale terminal](https://storage.googleapis.com/papyrus_images/cb6e922687f1a8caef5993229dea9a700d3baa6604a4d544e123082018961194.jpg) Restaurant point of sale terminal Ask an engineer to model a restaurant menu and you will usually get categories, items and prices. It is a reasonable first guess and it is wrong in a way that surfaces about three weeks into a pilot, when staff start typing things into the notes field because the system cannot express what a customer asked for. Menus are not the hard part. Modifiers are. And once free-text notes become the workaround, kitchen displays, inventory deduction and reporting all break simultaneously — because none of them can parse "no onion, sub sweet potato fries, med rare." What a single item actually requires ------------------------------------ Take a burger. In a real venue it carries: * **Doneness** — required, single-select, no price change * **Cheese** — optional, single-select, priced differently per option * **Extras** — multi-select, maximum three, priced per selection * **Side** — required, single-select, where swapping fries for salad is free but truffle fries add a charge * **Removals** — no onion, no sauce, which affect the kitchen ticket and inventory but not price Five distinct behaviours in one item. Now consider that a set menu constrains which mains are available, that a half-portion changes both price and recipe deduction, and that the same burger is priced differently on a delivery platform. A model of categories, items and prices cannot express any of this. Modifier groups as first-class entities --------------------------------------- Model modifier groups independently of items, and attach them by reference so a group can be shared. A single "Cooking Temperature" group serves every steak and burger on the menu, and changing it once changes it everywhere. Each group carries its own rules: ModifierGroup { id, name, selectionType: 'single' | 'multiple', required: boolean, minSelections, maxSelections, pricingStrategy: 'included' | 'per_option' | 'price_difference', options: [{ id, name, priceDelta, isDefault, available }] } The `price_difference` strategy is the one most often missing and the one restaurants use constantly: the side is included, but choosing an upgraded option charges the difference between them rather than a flat addition. Nesting matters too. Choosing a set menu should constrain the available mains; choosing a pizza size should change which crusts are offered. Support at least one level of conditional availability, because two-level menus are everywhere. ![Restaurant manager with a payment terminal](https://storage.googleapis.com/papyrus_images/e81df247327e62736ac3efe15f0bd7761e59d98e8bb53e6b070efdfe16832022.jpg) Restaurant manager with a payment terminal Menu versioning, and why it is not optional ------------------------------------------- Prices change. Items are seasonal. Recipes are reformulated. If a report covering last month is generated with today's prices, it will not match the till roll, and the operator will lose confidence in every number the system produces. Store menus as versions with effective dates, and record the menu version on every order line. Then a historical report reconstructs the prices that were actually in force. This is a small amount of work early and an unpleasant retrofit later, because orders written without a version reference cannot be repaired. The same applies to recipes for inventory deduction. Deducting today's recipe against last month's sales produces food cost figures that are quietly wrong. Channel-specific pricing and availability ----------------------------------------- The same item is sold in-house, for takeaway, and on two or three delivery platforms — frequently at different prices, sometimes with different names, and often available on one channel while unavailable on another. Delivery commissions mean menu prices are commonly marked up on those platforms to preserve margin. Model channel as a dimension on pricing and availability from the beginning. Teams that add it later as a set of flags end up with a permutation problem that leaks into every query touching the menu. Availability as a runtime concern --------------------------------- Availability is not a static attribute. An item is unavailable because the kitchen ran out, because it is outside its service window, because it is seasonal, or because a required modifier option is out of stock. Model these as distinct causes with distinct lifetimes. "Eighty-sixed for tonight" should restore automatically at the start of the next service; "off the menu for winter" should not. Collapsing them into one boolean flag guarantees that somebody manually re-enables items every morning, and eventually forgets. Why this pays off later ----------------------- There is a further reason to keep this data properly structured: it is the input to the features that actually reduce an operator's costs. Item-level demand forecasting drives prep sheets and supplier ordering. Recipe-level inventory deduction makes food cost reporting real rather than estimated. Menu engineering identifies items priced below the point of demand sensitivity. All of them require modifier-level, timestamped detail — including voids and removals — rather than settled check totals. A team that collapses orders into totals has discarded the input those features need, and that history cannot be reconstructed later. The modelling decision made in week three determines what is possible in year two. More on the applied side in our writing on [AI development services](https://techcirkle.com/ai-development-services). Full build guide: [Cloud Based Restaurant POS Systems: The 2026 Build Guide](https://techcirkle.com/blog/cloud-based-restaurant-pos-systems). Frequently Asked Questions -------------------------- ### How deep should modifier nesting go? One level of conditional availability covers the overwhelming majority of real menus. Arbitrary nesting is possible to build and difficult for staff to configure correctly, which produces menu setup errors that surface during service. Depth here is rarely worth its cost. ### Should modifiers deduct inventory? Yes, if inventory is tracked at all. A burger with extra cheese consumes a different quantity of cheese than one without, and a system that deducts only base recipes produces food cost figures that drift steadily away from reality. ### How do you handle a price change mid-service? Create a new menu version with an effective timestamp and let open checks retain the version they were opened with. Repricing an open check mid-service is surprising to both staff and customers and produces receipts that do not match what was quoted. ### Is a separate menu service worth building? For multi-location platforms, usually yes — menu management, versioning and channel pricing form a coherent bounded context with different read and write patterns from order processing. For a single-venue product, a well-isolated module is sufficient. ### What is the most common modifier modelling mistake? Treating modifiers as a flat list of options attached directly to an item, with no group-level selection rules. It works for the first ten menu items and then cannot express required-versus-optional, minimum and maximum selections, or price-difference upgrades — at which point staff fall back to free-text notes and the downstream systems break. --- *Originally published on [techcirkle](https://paragraph.com/@techcirkle/the-menu-modifier-problem-modelling-restaurant-data-properly)*