And once your menu is in, here is how far the pricing engine underneath actually goes:
🍕
Toppings priced per size, on one card
Pepperoni is $1.99 on a 9″, $2.99 on a 12″, $3.99 on a 16″ — one menu
item, one topping list, three prices. Most platforms store the price on the
modifier, so it is a single flat number; that is why the same menu ends up split into
three near-identical topping groups elsewhere. Here a price belongs to a context, and
the most specific match wins.
🎁
A free allowance, not a duplicate group
“First two toppings included” is a property of the item, not a separate menu
entry. Anything past the allowance falls through to the per-size price automatically, so
overage needs no second set of rules.
📝
Draft, preview, publish
Edits land on a draft, not on your live menu. Preview the whole thing, compare it against
what is published, then publish when it is right. Customers only ever see a published
version — no more a half-finished price change going out at the dinner rush.
🔑
Runs beside the POS you already have
It keeps its own menu and its own orders, so nothing has to be ripped out or migrated.
Online orders come through here instead of through your POS provider’s own storefront.
Orders don’t sync into your POS — they print on a dedicated kitchen printer we
set up, so the two systems never fight over a ticket.
📈
Built on your real menu, not a demo one
The pricing engine is tested against a real Atlantic-Canadian pizzeria menu — every
size, every topping, every combo — because the awkward cases are the whole point.