Re:Bite — 2-Tap Reorder for Weekly Meals

People who eat the same lunch every week shouldn't have to rebuild the order from scratch each time — pick the place, re-add each item, redo the customisations, reconfirm address and payment. That's ~10 taps to recreate something they've ordered 20+ times. And when an item is sold out or a price changed, today's apps make them start over instead of fixing it in place. For habitual orderers — office lunches, tiffins, WFH routines — this is exactly where they give up or just call the restaurant. Process I worked back from one job-to-be-done: "get me the meal I always get, in seconds — and tell me if something changed." Two goals only: fewer taps, more trust. I mapped the current reorder journey and counted the taps (~10), then collapsed it to two — tap your usual, tap place order. The real work wasn't the happy path; it was the messes: sold-out items, price changes, closed or delisted restaurants, an address they no longer deliver to, an expired card, a cart under the minimum. I made each one a clear state with a one-tap fix, and had the cart re-check itself after every fix — because removing a sold-out dish can quietly push you below the minimum. I deliberately left out search, discovery and tracking. They'd blur the one moment this is about. Results Reordering a usual went from ~10 taps to 2 — roughly 80% fewer — with nothing re-typed on the happy path. All 8 edge cases get fixed inline without dead-ending the user; the only genuine dead end (a delisted restaurant) sends them somewhere useful instead of erroring. What I'd do next, honestly: run a 5-person tap test to replace my projected numbers with real taps, time and task-success rates — and add "repeat this every week," since the behaviour is clearly a habit, not a one-off. With more time I'd handle a partial restaurant outage item-by-item instead of blocking the wh Reflection Honestly, I optimised for taps before I had real numbers — I should've run the 5-person test first and let the data set the target, instead of designing toward "2 taps" and validating after. I'd also rethink two calls: blocking the whole cart when only part of a restaurant is down (it should drop unavailable items per-item), and treating a price change as a non-blocking warning — for some people that needs an explicit confirm, so I'd A/B it. And I leaned so hard on speed I never checked whether 2 taps feels too fast — people may want a beat to feel in control before paying.