RecipeBox app PRD: save recipes, plan meals, and ship in 3 weekends

RecipeBox sits at a comfortable intersection: it has real data (recipes with structured ingredients), real value (the auto-generated shopping list), and a clear weekly habit (meal planning on Sunday). It's a bigger project than a habit tracker but smaller than a real SaaS. Lovable handles the v1 cleanly; v0 makes the meal-plan grid look great; either approach gets you to a usable app inside 3 to 4 weekends of focused work.

What this is

A RecipeBox app PRD documents a personal recipe library plus a weekly meal-planning surface plus an auto-generated shopping list grouped by grocery-store aisle. The MVP targets home cooks who are currently using a mix of bookmarked browser tabs, Notes app snippets, and paper grocery lists. v1 success looks like 30 weekly active users, each saving 10+ recipes and using the meal-plan view at least once a week.

Compared to alternatives

Option	Best for	Trade-off
Lovable	The Supabase schema + auth + CRUD shape fits perfectly	Drag-and-drop meal planner needs an extra prompting round
v0 + manual backend	Polished recipe cards and a beautiful meal-plan grid	Slower to v1; you'll wire Supabase by hand
Bolt with Next.js + Drizzle	Stack control + integrated dev loop	More setup; more choices to make
Notion (no code)	Fastest if you accept Notion's UI	No shopping-list logic; rigid layout
Paprika or Mealime	Existing products that do this	You're competing with them; only worth building if you have a strong differentiator
Cursor + Claude Code	Highest control for long-term build	Slowest to v1; best for v2+ once the product is validated

A real example

Filled example

A real, ready-to-customize version

Product Requirements Document — RecipeBox v1

TL;DR

A web app where home cooks save recipes with structured ingredients, build a weekly meal plan by assigning recipes to days, and auto-generate a shopping list grouped by aisle. Target: 30 weekly active users in 60 days, each with 10+ saved recipes. Differentiator from Paprika: free, web-first, and the shopping list is the headline feature.

Goals (business):

30 WAU within 60 days
70% of weekly users use the meal-plan view at least once per week
Self-funded; no paid tier in v1

Goals (user):

Save first recipe in under 2 minutes
Build a weekly meal plan in under 5 minutes from a 10+ recipe library
Shopping list grouped by aisle (produce, dairy, pantry, etc.) so a grocery run is fast

Personas:

Sara, working parent of 2: plans meals on Sunday, hates the "what do we have?" friction
David, single home cook: likes to try new recipes weekly; wants a place to save the keepers

Functional requirements (P0):

P0-1. Auth: email + magic link. Acceptance: signup-to-first-recipe under 3 minutes.
P0-2. Save a recipe with title, structured ingredients (name + quantity + unit), steps, tags. Acceptance: ingredient list parses into a typed array.
P0-3. List all saved recipes with filter by tag. Acceptance: 100-recipe library loads in under 1 second.
P0-4. Weekly meal-plan view: 7 days × up to 3 meals each, drag-and-drop assignment. Acceptance: drag works on desktop; tap-to-assign fallback on mobile.
P0-5. Shopping list generated from the weekly plan: groups by aisle, deduplicates ingredients, sums quantities. Acceptance: 5-recipe plan produces a correct grouped list with merged duplicates.

Functional requirements (P1):

P1-1. Mark items as already-have so they drop from the shopping list.
P1-2. Copy last week's meal plan as a starting point.

UX flow: 4 screens.

Sign-in
Recipe library (list + search + filter)
Recipe editor (create / edit a recipe)
Meal planner (week grid + shopping list panel)

Success metrics:

80% of new users save a recipe in their first session
50% of week-2 users return for week-3
Shopping list correctness: zero deduplication bugs across 100 generated lists

Technical considerations:

Stack: React + Supabase (Lovable defaults)
Deploy: Vercel
Ingredient parsing: simple regex for "2 cups flour" style; structured input form for ambiguous cases
Aisle mapping: a static ingredient_to_aisle table seeded with 500 common ingredients; fallback to "Other"

Lovable appendix — Supabase schema:

profiles (id uuid → users.id, name text)
recipes (id uuid, user_id uuid, title text, steps text, tags text[])
recipe_ingredients (id uuid, recipe_id uuid, name text, quantity numeric, unit text, sort_index int)
meal_plans (id uuid, user_id uuid, week_start date, unique (user_id, week_start))
meal_plan_entries (id uuid, meal_plan_id uuid, day_offset int, slot text, recipe_id uuid)
aisles (id text primary key, sort_index int) -- e.g., "produce", "dairy", "pantry"
ingredient_aisles (ingredient_name text primary key, aisle_id text)
RLS: user_id = auth.uid() on every user-owned table

Out of scope (v1):

Photo uploads for recipes (text-only in v1)
Nutrition data (calorie counts, macros)
Social sharing or public recipe library
Native mobile app (web is PWA-installable)
Imports from URLs (paste-only in v1)

How to use this

Start with Lovable. The schema is the heart of this app; Lovable wires it cleanly.
Seed the ingredient-to-aisle table early. 500 entries from a Sunday afternoon is enough for the v1; missing entries fall to "Other" which is fine.
Build the shopping-list generation logic before the meal-planner UI. The logic is the differentiator; the UI is table-stakes.
Use drag-and-drop on desktop only. Mobile gets tap-to-assign. Don't force drag-and-drop on touchscreens; it's worse than the alternative.
Test with 5 real cooks before launching. Watch them plan a real week. The friction shows up in the third or fourth recipe assignment.
Don't add nutrition data in v1. It's a rabbit hole (API costs, accuracy claims, dietary preferences) that distracts from the core loop.

FAQ

Is the shopping-list logic actually hard?

The dedup-and-sum is straightforward when units match (2 cups flour + 1 cup flour = 3 cups flour). It's harder when they don't (1 cup flour + 200g flour). For v1, dedup only when units are identical; show separate lines otherwise. Better unit conversion is a v2 feature; users tolerate the simple version.

Should I parse ingredients from URLs?

Tempting, but skip it in v1. URL parsing for recipes is unreliable (every site has a different markup), and the failure mode is poor (a malformed recipe is worse than no recipe). Add it in v2 once you know users actually paste URLs vs. typing recipes.

What about meal-prep mode (make-ahead Sunday cooking)?

Out of scope for v1. The basic week-by-meal grid covers 90% of the use case. Meal-prep is a power-user pattern; add it as a P2 once 100+ WAU justify the investment.

Why no nutrition data in v1?

Three reasons: it's expensive (USDA API rate limits, third-party costs), it's a rabbit hole (food users care about accuracy), and it's not the differentiator (Paprika has it; we don't compete on it). Save it for v2 if user research surfaces strong demand.

Should I build this if Paprika exists?

Yes, if the differentiator (free, web-first, aisle-grouped shopping list) lands with real users. No, if you're building it because you want to learn the stack and not because you actually want users. Either is a valid reason; only the first justifies a real launch.