A family meal planning app that goes well beyond storing recipes. Family members browse a shared library of ~50 curated recipes, add them to a basket, and get a smart shopping list that handles the real-world complexity: aggregated quantities, pack sizes, cost estimation, nutrition, and direct Ocado cart integration.
The Problem
I've always found it hard to summon the time and headspace to figure out what we're cooking that week, work out what ingredients we need, check what we already have, and get everything onto the shopping list before the Ocado slot closes. It's not difficult exactly, just enough friction that it rarely happens well.
I looked at what was out there. Plenty of recipe apps, a few meal planners, nothing that really closed the loop from "pick some meals" to "here's your shopping list, already added to your basket." So I built one.
The harder problem turned out to be everything the existing apps glossed over: how much do you actually need to buy, what will it cost, what's already in the cupboard, and how do you avoid buying two packs of something when one would cover both meals?
Why not use a tool that's already out there?
I did look properly. Mealime, Plan to Eat, Paprika, Whisk, AnyList, Cooklist — the main contenders all have genuine merits, but they share the same blind spots. Most treat meal planning as an organisation problem: browse recipes, pick some, get a list. The harder questions about cost, pack sizes, and what you already own are either absent entirely or handled in ways that quietly fail.
A few standout findings from digging into each one: Plan to Eat deliberately removed their pantry feature after concluding that keeping a digital inventory in sync with a real kitchen was effectively unsolvable without physical automation. Mealime's own support docs openly state that they can't estimate what your groceries will cost. Paprika's meal planner and shopping list are entirely separate features; adding a recipe to the planner doesn't add anything to the shopping list.
The pack size problem is the most overlooked. A 2024 paper in Resources, Conservation and Recycling specifically identifies discrete package sizes at the point of purchase as a primary driver of household food waste, and notes that meal planning apps haven't addressed it. No app in the category models the difference between what a recipe uses and what you actually have to buy.
| Mealime | Plan to Eat | Paprika | Whisk | AnyList | Cooklist | Recipe Hub | |
|---|---|---|---|---|---|---|---|
| Shopping list from meal plan | ~ | ✓ | — | ✓ | ✓ | ✓ | ✓ |
| Ingredient aggregation across recipes | ~ | ~ | ~ | ~ | ✓ | ~ | ✓ |
| Pack size awareness | — | — | — | — | — | — | ✓ |
| Cost estimation | — | — | — | — | — | ~ | ✓ |
| Pantry tracking | ~ | — | ~ | ~ | — | ~ | ✓ |
| UK supermarket integration | — | — | — | — | — | — | ✓ |
~ = limited or unreliable
Key Features
- Shared basket — family members add recipes collaboratively, all seeing the same view
- Smart shopping list — ingredients aggregated across all recipes before pack quantities are calculated
- Real cost breakdown — purchase cost (what you pay) and consumption value (what you use) tracked separately
- Ocado integration — shopping list added directly to an Ocado basket
- Pantry tracking — mark items already in stock and exclude them from the list
- Nutrition tracking — per-serving and total, sourced from actual product label data where available
- Product preferences — prefer premium, low-fat, low-carb, or low-sugar variants across all recipes
- Recipe variations — quick, slow, and from-scratch alternatives for each recipe
Solving Real Problems in Non-Obvious Ways
What a meal actually costs
No app in this category estimates grocery costs accurately, and the reason is straightforward: you can't buy 30ml of olive oil. You buy a bottle. The gap between what a recipe requires and what you actually have to purchase is where the real cost lives, and it varies depending on whether leftovers will spoil.
Recipe Hub tracks two separate figures: the purchase cost (whole packs, what you actually spend) and the consumption value (pro-rata for non-perishables, full pack for perishables). A 500g bag of rice used for 150g of a dish costs £1.50 to buy but £0.45 in consumption terms. A bunch of fresh herbs used for a garnish costs the full pack either way. Mealime explicitly doesn't attempt this; Cooklist shows real store prices but never models pack boundaries at all.
Never buying two packs when one would do
Even apps that do aggregate ingredients across recipes — AnyList and Whisk both do this reasonably well — stop at telling you the total quantity needed. They don't translate that into pack-level purchasing decisions.
If three recipes each need 80g of chicken, Recipe Hub aggregates to 240g before doing any pack calculation. One pack of 300g covers it. A naive approach calculates three separate pack quantities and either double-counts or leaves you guessing. The research paper above specifically flags this as an unsolved problem across the category.
The app handles whatever unit a recipe uses
Plan to Eat's aggregation breaks constantly in practice because recipes written by different people use different units and naming conventions. "Olive oil" and "EVOO" stay as separate list items. "4 Russet potatoes" and "6 pounds Russet potatoes" don't merge.
Recipe Hub sidesteps this by storing every ingredient in a canonical unit and running a conversion chain at calculation time: recipe unit to canonical unit to product yield. A recipe calling for two tablespoons of olive oil and another calling for 25ml both resolve to the same ingredient and aggregate correctly.
Nutrition you can trust
Ocado doesn't consistently provide nutrition labels, especially for fresh produce. Rather than silently falling back to estimates or returning zeros, the nutrition module works through an explicit hierarchy: product label data first, then any product with data, then ingredient-level estimates. The calculation degrades gracefully rather than quietly misleading.
Keeping the data honest
With 350+ ingredients each mapped to Ocado products with pricing, nutrition, and yield data, data integrity is a real concern. All data structures are defined as Zod schemas first; TypeScript types are inferred from them, and the same schemas validate API inputs at runtime. A dedicated audit script validates the full ingredient and recipe database on demand: schema conformance, missing product mappings, broken nutrition chains, missing images. Problems surface in a report rather than at runtime.
Built With
- Next.js 14 — App Router, Server Components, Server Actions for heavy calculations
- Supabase — Postgres for the ingredient database (~350 rows); basket and pantry state persistence
- Zod — schemas as the single source of truth for all data structures
- Tailwind CSS — styling
- Vercel — deployment with ISR cache invalidation
Can I Try Recipe Hub?
Not easily, and it's worth being honest about why.
The Ocado integration relies on unofficial access patterns rather than a supported API, which makes it fragile to distribute. Authentication is scoped to a single household, so there's no clean path to multi-user accounts without significant rework.
Content is the bigger challenge. I've built mechanisms for ingesting recipes from services like Gusto and HelloFresh, but distributing an app that uses that content isn't something I'd be comfortable doing.
If a company were interested in taking on the shell of the app — the planning logic, the cost modelling, the shopping list engine — and wanted to work with me to build it into something more commercial with properly licensed content and a supported supermarket integration, I'd be very open to that conversation.
Status
Active development. Core meal planning and shopping list generation working. Ocado integration live.