A UK household of four throws away food worth around £1,000 a year (WRAP, 2025), not because they buy too much, but because they can't decide what to make with what they already have. Toss attacks the decision gap, not the shopping list.
Framed the problem as decision friction rather than recipe discovery, through competitive benchmarking against 2 established recipe apps and informal conversations with prospective users. The gap was never a lack of recipes; it was the moment of standing at an open fridge with no answer
Applied MoSCoW across ingredient capture, recommendation output and expiry ranking as the algorithm’s primary sort key. Wrote functional and non-functional requirements with measurable acceptance criteria so "done" was arguable against evidence, not taste
6 DSDM timeboxes inside a fixed 126-hour window. All Must and Should requirements shipped on schedule, with 2 features agreed as Won’t at the outset and held there as a deliberate product call
Evaluated against Nielsen’s 10 usability heuristics. The most useful finding worked against my own design: a single recommendation did remove choice paralysis, but with nothing to compare it to, users had no way to judge whether the system had actually understood them
Carried the product past the submission deadline and acted on that finding. Rebuilt the output as three role-labelled options, collapsed ingredient capture into a single natural-language field with voice and photo input, and added an explicit transparency layer
Deployed to production and still live. The MVP proved the thesis under a hard constraint; the deployed version is what the evaluation said it needed to become
The MVP bet everything on removing choice. The deployed product makes a sharper bet: keep the decision small, but never make it opaque. The system still does the ranking; it just shows its working, and lets you argue with it in plain English.
One free-text field that takes how people actually talk ("half a courgette, some leftover chickpeas"), with voice and camera capture beside it and one-tap chips for everything already in your pantry. Structured multi-step entry was the MVP approach; it turned out to be the tax that stopped people using it at all.
Not a ranked list to evaluate: three suggestions with the comparison already done. Most Urgent, Balanced Pick, Stretch Cook, each quantified by how much of your pantry it uses and how many expiring items it rescues. The user picks a posture for the evening; the system still picks the recipe.
Every generated recipe carries an explicit AI transparency notice, tags each ingredient as yours or model-added, and will state in plain language which expiring items it prioritised and why. If the answer is wrong you refine it by saying so: "make it vegetarian", or "use less butter".
The DSDM timebox did more for the product than for the schedule. A hard 126 hours forced MoSCoW to be honest: 2 features agreed as Won’t at the outset and held there cost less than half-building them would have. The expiry-first ranking was the right core bet; it survived every later rewrite untouched.
I built before I validated. All of the input handling was finished before I had evidence about what capture actually cost people, and the recommendation model was settled before heuristic evaluation told me a lone suggestion reads as arbitrary. Both findings arrived late enough that acting on them meant rebuilding after submission rather than iterating inside a timebox. I would now spend an early timebox on evaluation and treat its output as a requirement.
Mobile-first rebuild with a shared household pantry, so the person who buys the food and the person who cooks it are looking at the same list. Impact tracking that reports items rescued and spend recovered per week; the product currently asks users to take the food waste benefit on faith. Longer term, supermarket loyalty integration to seed the pantry automatically and remove the last of the input cost.