Order lifecycle
What happens after a customer orders
Six steps every restaurant ordering system has to get right, and the places where they break. Click through; each step shows what I built or fixed there.
01Guest orders
- What happens
- A guest browses the menu, customises items and checks out on the web or in the app.
- Where it breaks
- Menu, prices and availability drift from what the restaurant actually has.
- My part
- Builtcustomer ordering flows across menu, basket, fulfilment options, tips and checkout at CraveUp, and the ordering contracts for a multi-location app.
02Payment
- What happens
- The payment provider authorises the card and the app confirms the order to the guest.
- Where it breaks
- The payment succeeds but the confirmation step fails, so the guest believes the order failed and orders again.
- My part
- Fixedexactly that on a live platform: a dropped null in the checkout session affected about 3 in 100 new-card checkouts; no recurrences after release.
03Order record
- What happens
- The order service stores one order with its items, time, location and status. Every other screen reads from it.
- Where it breaks
- Two records for one order, or an order that exists but no one can see.
- My part
- Fixedorder history for thousands of customers, and caught a duplicate-record path and a wildcard email match in review before release.
04POS & providers
- What happens
- The order is sent to the point-of-sale or ordering provider, which sends status events back through webhooks.
- Where it breaks
- The connection is configured on one side only: orders go out and nothing comes back.
- My part
- Builtthe catalog import and outbound-order path for an external POS, and Diagnoseda launch-week case where the provider webhook had never been configured. Square and Clover integration engineering at Crave.
05Staff prepare
- What happens
- The order appears on the staff tablet or printer and moves through received, preparing and ready.
- Where it breaks
- Orders missing from the staff screen at the busiest moment, or a printer that silently drops tickets.
- My part
- Builtthe React Native order-manager printer workflow, and Fixedlaunch-day order visibility in the merchant dashboard.
06Same status everywhere
- What happens
- The guest tracks the order, support can look it up, the merchant sees it in analytics and finance reconciles the payment.
- Where it breaks
- A connection or session quietly breaks and every signed-in screen fails at once.
- My part
- Fixeda half-open Redis connection by making it self-healing after it took every signed-in feature down twice in one afternoon. Settlement reconciliation work on CraveUp's Square and Clover integrations.
Step 1 of 6
A generic restaurant ordering system, drawn from the CraveUp and multi-location platform cases. No client screens or data.