Problem
Home cooks waste time jumping between tabs and recipes to find something that matches what’s actually in their pantry. Most apps optimize for search by title, not ingredients on hand.
Goals
Research
- 6 interviews + competitive scan (NYT Cooking, Allrecipes, Tasty)
- Users start from ingredients → Pantry as a top-level route
- Time is a hard constraint → minutes slider + time chips on cards
- Users skim image + title → denser cards with small thumbnails
Information architecture & flows
Routes
- Home (value prop)
- Finder (keywords/filters)
- Pantry (ingredients)
- Detail (ingredients + steps)
Critical flows
- Search → Results → Detail
- Select ingredients → Results → Detail
Design system
- Accessible palette + type scale (mobile-first)
- Search bar, filters, result cards with time/diet chips
- Empty & error states for resilience
- Detail: large hero image, readable steps, ingredients list
Build
Frontend
- React + TypeScript + MUI
- Hash Router for GitHub Pages
- TanStack Query for async data + caching
Backend & infra
- Express proxy/cache to recipe API
- Prisma + Postgres for favorites
- API on Render · site on GitHub Pages
Performance notes
Result lists are cached by normalized query keys; Pantry selections are debounced; images are responsive and lazy-loaded.
Impact
- Pantry path reached recipe detail 2× faster than keyword search (pilot)
- Users reported cooking with “what I already have” more often
Next
- Favorites + shopping list
- Nutrition details
- PWA + offline cache