Dish Database
Because "what's for dinner?" shouldn't require a existential crisis every single night.
How Dish Database Escaped The Idea Graveyard
A full-stack dish manager born from the eternal struggle of staring into the fridge. 50 recipes from a static JSON dataset, a real-time Convex backend for weekly plans, cooking history, and ratings. Browse and filter dishes, generate randomized weekly meal schedules with auto-scaled ingredients, track every cooking session with ratings and warnings, and sync your grocery list straight to Grocy. Past-you helping future-you eat better.
Genesis Spark
Started as a borderline ridiculous experiment that somehow refused to die during refactors.
The first proof-of-concept was duct-taped together in under 48 hours. It broke. A lot. But the core loop felt magical enough to justify polishing instead of abandoning. That was the moment it graduated from "random script" to "this might become real".
Core Problem & Insight
Beneath the jokes sits a very real friction: people kept wrestling with inefficient, boring, or psychologically draining workflows. That emotional tax became the design compass.
Known Chaos
- Keeping a static JSON file as the single source of truth for recipes while persisting plans, history, and feedback in a real-time database—without them drifting apart like two people reading different menus.
- Locking down the app to a single owner without spinning up a full multi-tenant auth system—nobody else needs to see my questionable meal ratings.
- Scaling ingredient quantities by people count and aggregating them across an entire weekly plan into one shopping list that doesn't list "olive oil" seven times.
Solutions
- Recipes live in the repo as static JSON—Convex only stores the dynamic stuff (weekly plans, cooking sessions, feedback, ingredient mappings, settings). Zero sync headaches, dishes stay immutable.
- Convex Auth with magic-link login plus a server-side owner gate: one configured user, one check, done. Every plan/history/integration mutation is locked behind it.
- Client-side plan generation picks season-aware random meals and desserts, then a shared shopping-list builder aggregates ingredients, scales by people count, and deduplicates by normalized name before shipping to Grocy.
Architecture Philosophy
Pragmatic modularity over premature perfection. Each subsystem is isolated enough to be refactored ruthlessly, but integrated just enough to keep velocity absurdly high.
Next.js
A React framework for building server-side rendered and static web applications.
React
A JavaScript library for building user interfaces using a component-based architecture.
TypeScript
A typed superset of JavaScript that compiles to plain JavaScript.
Convex
A full-stack TypeScript development platform with a real-time reactive database.
Convex Auth
An authentication solution built for Convex applications.
Tailwind
A utility-first CSS framework for rapidly building custom user interfaces.
Vercel
A cloud platform for static sites and Serverless Functions that fits perfectly with your workflow.
Screenshots That Don't Lie
Visual proof that this thing actually works
Ready to Experience the Magic?
Don't just read about it, go play with it! (We're not responsible for productivity loss)