tapa.
Built a recipe app for every day and kept it radically simple — your ingredients in, one well-considered recipe out — because life needs more simple, and simplicity is a discipline, not a shortcut.
tapa. answers one question: “what can I cook with this?” Tell it or show it what you have, say how long you want to cook and for how many people, and it gives you one well-considered recipe. Not fifty search results. One good answer. The case study is about what keeping something that simple actually costs.
The mental load nobody prices in
Eating is a basic need, and deciding what to eat is somehow the most mentally taxing part of the day. First you work out what you have, then what could be made from it, and because that is monotonous you end up cooking the same three things forever. Recipe sites answer the question with fifty results and a life story above each one — which is more deciding, not less.
tapa. deletes the decision. Type, say, or photograph what is in the fridge, set a time and a serving count, and get one recipe tailored to your tastes. Allergies and dietary needs are set once and enforced as hard rules on every generation — a safety constraint, not a preference.
Simple on purpose
Every number in the product is small, and each one is a decision to leave something out:
- 3 → 1
- Ways in, one recipe outType it, say it, or photograph it — and one recipe comes back. Choice is the load the app exists to remove, so it never returns a list.
- 1×
- Set your constraints onceAllergies, dietary rules, household size, skill — captured in onboarding, applied to every recipe after, editable any time.
- 3
- Recipes of historyEnough to go back to last night, not enough to become a database you manage. Favourites are saved deliberately or not at all.
The same discipline runs through the engineering: when a second account on a shared phone could see the first account's recipes, the fix was ownership at the data layer — every row belongs to an account, not a device — rather than a patch on the sign-out path.
Finding the free tier honestly
A simple app still has to sustain itself. The free allowance was tuned in public view of the numbers — how often people actually cook, what competing apps give away — and the journey is worth showing because each move had a reason.
| Iteration | Free recipes per week | What changed |
|---|---|---|
| Launch | 3 | Generous — but the median cook makes 3–4 dinners a week, so free covered everything and the question of upgrading never arrived. |
| Revision | 1 | Too far the other way. Live for roughly an hour before the reasoning was rechecked. |
| Settled | 2 | Real weekly value free, and anyone cooking regularly meets the upgrade question at a genuine moment of need. |
The aim was an exchange that is fair in both directions — worth it for the user, sustainable for the business — set from how people actually cook rather than from hope. And a matching honesty rule ships in the code: upsell copy is derived from the configuration that enforces it, so the app can only ever promise what it actually delivers.
The screens
What I'd do differently
Own the data properly from the first schema. Local recipes belonged to the phone, not the account, until a TestFlight tester signed into a fresh account and saw someone else's saved recipes. The fix — every row owned by a user, enforced at the data layer — was always the right design; it should not have taken a stranger's recipe list to prove it.
And I would research the free tier before launch rather than in public. It moved from three recipes a week to one to two inside two days — each step reasoned and documented, but the cooking-frequency data that settled it existed all along. The habit this project actually taught me: check how people already behave before deciding what to charge them for.