Delivery apps optimize for taste, not for state
Open any food delivery app and the sort options are some version of rating, price, or delivery time - all proxies for "what do I feel like eating," a static preference that barely changes day to day. But what someone actually needs from a meal changes constantly, and it has almost nothing to do with taste preference: a student cramming for a final needs sustained focus without a sugar crash an hour later. Someone who just finished a hard workout needs protein and recovery, not comfort food. Someone three hours into a night shift needs to stay alert, not get sleepy.
None of that context exists in today's delivery apps. Whether you're wired on adrenaline, running on four hours of sleep, or nursing sore muscles, you get the same ranked list of nearby restaurants. The apps have gotten very good at predicting what you'll click on - and never asked what you actually need.
Rally starts from a different question than "what do you want to eat?" It asks "what state are you in right now, and what food actually helps?" - then reorders the menu around the answer.
Where this stands
Rally is currently a problem framing, not a designed product yet. The open questions I'd want to work through next: how someone communicates their state without it feeling like a survey (a mood picker? inferred from calendar/wearable data? a one-tap check-in?), how "helpful for this state" gets mapped to actual menu items without oversimplifying nutrition into a gimmick, and how the app stays useful on days when someone genuinely just wants comfort food regardless of state.
Case study in progress - personas, the state-to-food mapping logic, and early flows will be added here as the design work starts.