Do we deliver there, and is the order big enough?

Domino Ra'anana has taken orders through the site we built for it for more than five years. It took about two months to build, and the owner, Eran Atra, changes the menu, the deals and the delivery areas himself. Customers notice the menu. The piece that decides whether an order is possible at all is much smaller and never gets looked at: a list of delivery zones, each one carrying its own delivery cost and its own minimum order amount.

Those two values per zone are not labels on a checkout screen. They are a gate. Given an address and a cart, they answer one question — can this order be completed as a delivery, or not. Get it wrong and you are not showing a slightly inaccurate fee. You are taking money for an order the branch cannot fill.

Every delivery business already has this rule. It just lives in people. The driver knows which streets are too far to be worth it. Whoever answers the phone knows that a small order to the far end of town does not pay for the drive, and says so politely. None of that survives the move to a website, because on a website there is nobody on the line to make the call.

So the rule has to be written down as data before anyone writes code. In practice that means being specific about four things per zone. Vagueness in any one of them turns into either a checkout that blocks orders you wanted, or a kitchen that receives orders it cannot serve.

The order flow on the Domino site runs in a fixed sequence. A pending order is created first. The customer is sent to Cardcom to pay. Only after payment succeeds does the order get its status update, the confirmation email, and the handoff into the Aviv POS at the branch so nobody retypes it at the register.

That sequence is exactly why the zone rules have to be settled early. Every step after Cardcom is expensive to undo. A refund is a support conversation and a payment fee. An order that has already reached the POS has been seen by the kitchen. You cannot fix that order afterwards — you can only refund it and phone the customer. So eligibility, meaning is this address in a zone and does the cart clear that zone's minimum, has to be decided before the pending order is created.

The site also takes cash orders, which skip Cardcom entirely. That path is shorter, and it is the one people forget when they attach the eligibility check to the payment step: a cash order still lands in the POS and still commits a driver. Two ways to place an order means the zone rule has to sit somewhere both of them pass through, rather than in the card flow because that is where it happened to get written first.

It follows that the check cannot live only in the checkout screen. Whatever code creates the pending order is the last honest place to ask the question, and it should ask it there too, even if the button that leads to it was already disabled.

A zone list with a cost and a minimum attached to each zone is one option out of three, and choosing between them is a business decision more than a technical one. What changes between them is where the ongoing work sits: in deciding boundaries, in an external service, or in absorbing costs quietly.

A blocked checkout is only infuriating when it arrives as a surprise at the end. The useful moment is earlier. Once a delivery zone is selected, the cart can show that zone's delivery cost and how far the order still is from the minimum. Now the customer has two reasonable moves — add something, or switch to pickup — instead of one dead end.

One detail matters more than it sounds. Hold on to that state. On the Domino site the cart, the delivery method, the selected zone, the payment method and the checkout form fields are all persisted in localStorage. People order food on a phone while doing something else, and they do reload the page mid-order. Losing the bag and the zone at that point loses the order.

Then there is the address that sits right on a line. Someone is always just outside a zone, and no set of boundaries removes that case. The phone is the answer there — the branch can take the order and charge whatever it thinks is fair. What the site should not do is guess on the customer's behalf, either by quietly stretching a zone or by acting as though the address does not exist. Show which zone was matched, show that zone's cost and minimum, and keep a way to reach a person visible.

Zone rules change. Fuel gets more expensive, a new neighbourhood fills in, a courier arrangement shifts. The build includes management screens for products, deals, categories, pizza sizes, beverages, sauces, delivery zones, site settings and orders, so a delivery cost or a minimum is a field the owner edits in a form.

Two of those settings are worth singling out, because they are the ones a manual system gets wrong most often, and they are not really about delivery at all — they are about when the shop is open. Friday closing and Saturday-night opening move every week, so the admin computes them instead of storing them. Opening is set to a fixed number of minutes after Shabbat ends in Ra'anana, resolved from the Hebcal API, and the screen shows the owner both the Shabbat-end time it read and the opening time it derived, with a link back to the source so the number is checkable rather than trusted. Friday closing is defined as one time under winter clock and another under summer clock, and the screen states which one is in force this week. That last line matters more than it looks: the bug this design prevents is a shop that closes an hour late twice a year, on exactly the two weekends nobody is checking.

There is a small pleasing detail in this. Hebcal is the same API behind Mincha Time's prayer-time reminders, one of the other builds on this site. In one product it decides when to send a notification; in the other it decides when a pizza shop starts taking delivery orders. The engineering is nearly identical — call the source once per location per day, store the answer, derive the local rule from it — and only the business meaning changes.

The alternative is worth pricing out honestly. Our post-launch work is billed hourly, $85 to $165 per hour, for hours actually worked, and we do not sell a standing monthly retainer for a small system like this. Even at the bottom of that range, a hard-coded delivery fee makes every adjustment a paid ticket, a deploy and a wait. Over a site that has been in daily use for more than five years, that is the difference between a number the owner controls and a number he has to book time to change. If you are sizing a build like this, our guide to what a small business app costs lists the ranges we actually quote, and the guide to software maintenance after launch covers what that hourly work usually goes on.

The rule works, but it lives in an awkward place. Most of the zone logic is enforced inside the checkout page, which is the hardest part of the app to test — to confirm that a minimum behaves correctly you have to render the whole checkout and drive it by hand. Starting again, pricing, minimums and delivery rules would go into shared pure functions that can be tested on their own, with the checkout page calling them.

The second change is visibility. Payment, the confirmation email and the POS handoff each happen at their own moment, and when one of them fails the evidence is spread across three places. A per-order event timeline staff can open — payment result, email sent, POS accepted — would make a bad evening explainable while it is still going on.

Any business whose service depends on where the customer is has the same rule hiding inside it. A mobile repair service has a travel radius and a smallest job worth driving to. A caterer has a delivery area and an order floor. A clinic has appointment types it will only do at certain locations. In each case somebody currently makes the call by feel, and the automation only works once that call is written down: a list of areas, and per area, what it costs and what the smallest acceptable job is.

The booking and order flows we build follow the same shape as this checkout. Settle eligibility before anything irreversible happens, and put the numbers where the owner can change them without calling a developer. If you can name your areas and, for each one, state the delivery cost and the smallest order you will send, you already have the rule written. The remaining work is a form and a check in the right place.