Stack
Why this was the right shape
The Domino Ra'anana build looks like a menu site from the outside, but the real work is operational. A pizza order touches product availability, deals, toppings, delivery zones, payment status, customer messages, admin visibility, and the point-of-sale flow.
The important product decision was to treat checkout as the center of the system, not as the final screen after the design was finished.
Key build decisions
Menu, deals, and products share one cart
The menu combines active products and active deals, with deals shown first. Both paths write structured cart items so checkout can calculate totals consistently.
Local cart state keeps ordering fast
Cart, delivery method, selected delivery zone, payment method, and checkout form fields are persisted in localStorage to reduce accidental loss during the order flow.
Admin operations are part of the build
The project includes management screens for products, deals, categories, pizza sizes, beverages, sauces, delivery zones, site settings, and orders.
Payment and POS are treated separately
Credit-card orders create a pending order and Cardcom payment URL first; successful payment updates the order and then runs post-order handling, including email and Aviv POS delivery.
What shipped
- Public menu with search, category filtering, products, deals, and configurable add-ons.
- Cart and checkout flow for delivery or pickup.
- Cardcom payment iframe path for card payments and a cash-order path.
- Customer and admin email templates with full order details.
- Aviv POS order handoff and test pages for payment/POS validation.
What got tricky
- Deals are not just discounted products. A deal can contain multiple products and its own selectable options, so the cart had to preserve deal structure instead of flattening everything too early.
- Payment success is asynchronous. The site must handle an order that exists before payment is completed, then update status, send messages, clear the cart, and send to POS only after success.
- Delivery zones have operational rules — delivery cost and minimum order amount — that affect checkout eligibility, not just display.
What we would improve next time
- Move more checkout validation into shared pure functions so pricing, minimums, and delivery rules can be tested without rendering the full checkout page.
- Add an internal event timeline per order, so staff can see payment, email, and POS handoff status in one place.
- Add a lightweight abandoned-cart follow-up only if the branch sees enough dropped orders to justify it.
Want a teardown like this for your own workflow?
Send the current process, the tools involved, and what keeps breaking. We can usually find the smallest useful build before anyone writes code.
Talk through a project