PizzaOS Book a demo

How it works

Draw where you deliver, and charge what it actually costs

A circle drawn around the shop crosses a river, a highway and a neighbourhood you will not drive to at 11pm. PizzaOS zones are polygons. Each one carries its own delivery fee, its own order minimum and its own promise time, and an address is matched to one of them before the customer is quoted anything.

Three zones, three prices, one map.

Zones are drawn, not derived. They can be any shape, they can follow the streets you actually drive, and the fee attaches to the shape.

Illustrative zones and figures, chosen so the sums are easy to follow. They are not a real shop's delivery schedule.

Three delivery zones drawn as polygons around one shop An outer polygon, a middle polygon and an inner polygon, nested around a shop marker. Two addresses fall inside zones; a third falls outside every polygon and is not deliverable. Zone 3 · $6.50 · $30.00 min · 50 min Zone 2 · $3.95 · $20.00 min · 35 min Zone 1 · $2.50 · $15.00 min · 25 min The shop $2.50 · 25 min $6.50 · 50 min Outside every zone
The same polygons the dispatch board draws, with the same fee and minimum hung on each one.
Zone Distance Fee Minimum Promise
Zone 1 — Close-in 0–2 miles $2.50 $15.00 25 min
Zone 2 — Across the bridge 2–5 miles $3.95 $20.00 35 min
Zone 3 — Extended 5–8 miles $6.50 $30.00 50 min

What happens at the edge of the map.

This is the part no vendor writes down. An address either lands in a polygon or it does not, and the honest answer to "it did not" is not a default fee. Containment is decided on the server, against the drawn boundaries — the browser's own coordinates are never forwarded, so a customer cannot claim to be somewhere cheaper than they are.

The address is inside a zone

The storefront shows that zone by name, with its delivery fee, its order minimum and its promise time. The fee comes from the zone the address actually landed in — there is no single shop-wide delivery charge to fall back on.

The address is inside no zone

The lookup answers 404 and the storefront says the address is outside the delivery area. No fee is shown, because there is no zone to take one from. The order does not proceed as a delivery on a guessed price.

The lookup cannot be reached

The customer is told plainly that the delivery fee has not been quoted, and is asked to try again. An earlier version left a fallback default standing, so an outage looked like a confident, invented delivery charge. That default is gone.

The postcode is never the decision

Postcodes span zones, overlap each other and cut across polygon edges, so matching on one produces both false approvals and false refusals. The address is geocoded on the server and the containment test runs against the drawn boundary. A postcode is only ever used to sharpen an ambiguous street line before geocoding.

The dispatcher sees the same shapes.

The dispatch board plots every zone as a polygon over the live map, with the fee and the order minimum on a label at the middle of it, and the drivers and open runs on top. One picture, not a settings page.

An inactive zone is drawn grey and priced at nothing

A zone you have switched off still appears — greyed, marked inactive — and carries no price label. You can see the shape you turned off instead of wondering where it went.

Fees are rendered cent-exact

Both figures on the label are integer-exact. A minimum is not rounded to the nearest dollar: rounding it up overstates a threshold the customer is held to, and rounding it down makes an order look eligible when it is not.

If the zones cannot be read, none are drawn

A failed zone read shows a banner saying the zone overlay is unavailable — the shapes and the prices are simply absent. Drivers and runs keep plotting, because a dispatcher needs those and they come from somewhere else.

Who sets the fees, and where.

Zone economics belong to the business, not to the app. When a new store is opened, the tier schedule — names, fees, minimums, promise minutes — is read from your own configuration and written to the store's zones. A franchise with different economics changes the schedule; nobody ships a release.

No invented tiers

If the schedule is missing or malformed, onboarding says the zone template is unavailable and seeds nothing. There is no fallback price list. One bad tier rejects the whole schedule, because a half-parsed fee is a made-up fee.

A tier without a boundary matches nothing — and says so

Seeding the schedule creates the zones and their prices. Until a boundary is drawn for a zone, it will not match an address, and the system does not pretend otherwise.

A fee change is believed only once it lands

An edited fee is read back from the server's own response, never echoed from what was typed. If the response does not carry the money field, the change is refused rather than displayed. A delivery fee that looks saved and quietly reverts is a revenue defect.