Product design: a delivery app built for kitchens and food sellers rather than diners

Design a food delivery app whose users are restaurant owners and food vendors, not the people ordering the food. ```hint Follow one order Trace what happens in a busy kitchen or at a food stall from the moment an order comes in until a courier leaves with it. The friction along that path, and how it differs between a staffed restaurant and a vendor working alone, is where your design should start. ``` ### Clarifying Questions - Is this the seller side of a consumer delivery marketplace, where diners order from these businesses, or a supply app through which restaurants buy ingredients from food vendors? - Does the platform provide couriers, or do the businesses deliver with their own staff? - Which sellers matter most: established restaurants with counter staff, or small vendors such as food trucks, market stalls and home kitchens run by one or two people? - Is this a new marketplace that starts with no sellers, or a replacement for an existing seller tool? ### What a Strong Answer Covers - A clear call on what the app is for, and the goal it serves for both the sellers and the platform. - Seller segments with different needs, from staffed restaurants to one-person vendors, and a justified focus. - The seller's order journey during a rush and the pain points it exposes: missed orders, prep timing, items running out, courier handoff and payouts. - Prioritized features with a first release that fits a noisy, busy kitchen. - Seller-side success metrics, with guardrails such as cancellations, diner ratings and hours sellers stay open. ### Follow-up Questions - Many small vendors already juggle orders from two or three delivery platforms. How does that change your design and your adoption plan? - A vendor cooking alone cannot look at a screen mid-rush. How would order intake and status updates work for them? - Your north-star metric is rising, but diner complaints about late food are rising too. How do you investigate?