Building a pizza menu

Pizza is the hardest common menu to model. One item carries a size, a crust, a sauce, a cheese decision and an open-ended list of toppings, and the combinations run into the thousands. Every pizza POS conversation is really a conversation about how that configuration is structured.

Check this before anything else

One limit to establish up front, because it is the most pizza-specific feature there is: Opero does not support half-and-half or fractional toppings. A topping applies to the whole pizza or not at all — there is no left-half, right-half or quarter placement.

If a meaningful share of your orders are half-and-half, that is a genuine gap and you should weigh it seriously rather than assume a workaround. Some shops handle it by listing a small number of fixed combination pizzas, and some take the note and price it manually, but neither is the same as the feature and it would be misleading to pretend otherwise.

Structure sizes and crusts as required choices

Size is the cleanest example of a genuinely required choice — no default is sensible, and it changes both price and cost materially. Crust usually is too, though many shops have a house default that most guests accept.

• ✓Use one required size group with per-option price differences rather than separate items per size. Three items called Small, Medium and Large is three products to maintain and three sets of reporting to reconcile.
• ✓Put crust in its own group, with a default if you have a house standard.
• ✓Order options by popularity, not size order or alphabetically — the most-ordered size should be the first thing anyone sees.
• ✓Keep the price step between sizes proportionate. A steep jump pushes everyone to the smallest and flattens your average.

Toppings are where the setup earns its keep

• ✓One optional group for toppings, with a sensible maximum. An unlimited group will eventually produce a pizza the oven cannot cook properly.
• ✓Price toppings individually where cost differs materially — a premium meat is not a herb, and charging one rate for both is a leak on the expensive one.
• ✓Name them the way the kitchen says them, since the same text reaches the make line.
• ✓Watch how price scales with size. A topping on a large costs meaningfully more product than on a small, and a flat topping price across sizes quietly erodes margin on the biggest pies.

Keep the make line readable

Everything above is really about what the ticket looks like at the make station. A pizza described as a base plus a long modifier list is slower to read than a named pie, and reading speed at the make line is throughput during your only busy period.

How this works in Opero

Modifier groups carry per-option pricing with minimum, maximum and required settings, and selection rules are validated on the server rather than trusted from whichever surface sent the order — so a kiosk, a phone and the counter cannot disagree about what a valid pizza is.

Availability is per location, so one shop running out of a topping removes it from that shop's ordering screens without touching another. Recipe costing sits on the same spine, which is what makes the topping-versus-size margin question answerable rather than theoretical; it is on the Growth plan and above.