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.
9 media files · rebite-reorder-743502904048.asia-south1.run.appView 
