Box of Chocolates
A meal-and-activity randomizer that ends the nightly "what should we eat?" negotiation.
Role
Design Engineering
Product
Mobile app
The problem
My wife and I like to cook, and we have plenty of places we love to eat. The problem was never a lack of options. It was agreeing on one, every single night. Deciding what's for dinner is a small decision made 365 times a year, and the cost is cumulative: it's exhausting, and it quietly eats into the evening before it has even started.
Existing tools don't solve this. Restaurant apps are built for discovery (they hand you more options), and a coin flip ignores everything we know about what we want tonight. We needed something in between: randomness with guardrails.
My role and constraints
I did everything solo: problem framing, scoping, flows, wireframes, and visual design. Working alone forced a rule I'd recommend to any team: scope the MVP around the one decision the product exists to make. That decision is picking dinner, so restaurant data comes first, and activities come later as an expansion.
Process
Sketches first. Rough flows on paper to test the core loop (set criteria, spin, accept or re-roll) before opening Figma.
Figma wireframes. Moved the strongest sketch into wires, focusing on three moments: setting criteria, the randomizer itself, and the result.
Structured build process. For the build, I'm following my own app-building process guide I built while learning the process during production of Stax. The pipeline moves from idea (competitive analysis, synopsis, goals) to wireframes in Figma, to a build with Claude Code and Xcode, to App Store release, producing specs and docs at each stage.
Building a process guide mattered here: it showed me how to not just ship one app, but I've built a repeatable way to get from idea to released product, "zero to shipped".
Key decisions
Include and exclude, not just filter. Most apps only let you narrow down ("Thai"). Real decisions are phrased both ways: "I want Thai or Chinese tonight" and "I'm up for anything but Italian." Supporting both inclusion and exclusion matches how couples actually negotiate, since vetoing is often easier than choosing. This is the central interaction of the product.
Constraints that reflect real life. Additional filters (distance from home, drive vs. walk, budget, new vs. favorite) exist because "good" depends on the night. Each one is optional so the default stays fast.
Randomness you can trust. The user sets the rules and the app makes the pick. The design question is how much control to leave after the spin (re-roll, lock a criterion, accept).
Scope: meals now, activities later. Restaurant data first, because it keeps the MVP to one data source and one decision. Activities reuse the same include/exclude model, so the architecture is built to expand without a redesign.