tapa.
Adulting, minus one decision. Tell it what you have and get a meal back — convenience and variety without the mental load of deciding.
tapa. answers one question: “what can I cook with this?” Tell it or show it what you have, how long you have and how many you are feeding. One considered recipe back, not fifty results. This is what keeping it that simple costs.
The mental load nobody prices in
Deciding what to eat is the most taxing part of the day. Work out what you have, then what it could become, and because that is tedious you cook the same three things forever. Recipe sites answer with fifty results and a life story above each — 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 on every generation — safety, not 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 fair in both directions, set from how people actually cook rather than from hope. The honesty rule ships in the code: upsell copy is derived from the configuration that enforces it, so the app can only promise what it 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. Every row owned by a user, enforced at the data layer, was always the right design.
Research the free tier before launch, not in public. It went from three recipes a week to one to two inside two days, and the cooking-frequency data that settled it existed all along. Check how people already behave before deciding what to charge for.