We taught the system every way a customer can order an item — by quantity, by weight, by configurable options and more — so the upcoming online ordering experience is built on a foundation that matches how the store really works.
Watch the 45-second recap
What’s new
Not every product is a single barcode on a shelf. People order by quantity, by weight, by a configurable option, or “about this much.” The system now recognizes each of these, so when online ordering arrives it can offer the right options for every product.
For the technically curious
Introduced a counter-product taxonomy in the data layer: every product is now classified by pricing unit (per-unit vs each) and one of seven fulfillment shapes, with per-shape invariants enforced and formatter helpers consuming the classification. No customer- or staff-facing output changed — this is foundational schema work.
pricingUnit + fulfillmentShape discriminator types (7-shape enum)VALID_FULFILLMENT_MATRIX constant + validateFulfillment() helperdemo-1001 snapshot to carry the new fieldsWhat’s next
Customers will see the full catalog — including the daily featured items.
The ordering flow itself: placing and switching a request across the customer’s order and the staff fulfillment queue.
Foundation first: with the data model settled, each next step changes a smaller part of the system and stays easy to review and trust.
The system now describes every way customers order at the counter — the online ordering experience is next.