I’ve been working on Grubl, an AI-powered cooking assistant focused on solving a surprisingly persistent problem: the daily “what’s for dinner?” decision.
Most recipe apps are essentially searchable databases. I wanted to experiment with something more adaptive — a system that combines LLM reasoning with structured recipe data and user constraints (budget, time, dietary preferences, household size).
Grubl currently supports:
Recipe generation from mood, cuisine, or available ingredients
“Fridge mode” (turn ingredients into meal suggestions)
Weekly meal planning with ingredient reuse optimisation
Auto-generated shopping lists
Nutrition-aware adjustments (macros per serving)
Step-by-step live cooking mode with timers
Basic taste preference learning
Some interesting implementation details:
Recipes are generated in structured JSON format rather than free text. This allows scaling, macro recalculation, cost estimation, and timer extraction.
Ingredient ontology mapping is used to normalise synonyms (“scallion” vs “spring onion”, etc.).
Meal planning attempts to reduce waste by reusing ingredients across days rather than treating each recipe independently.
User preferences are stored and used to bias generation weights (e.g., spice tolerance, disliked ingredients).
Things that turned out harder than expected:
Optimising weekly plans across cost, nutrition, time, and ingredient reuse simultaneously.
Making AI-generated recipes consistent enough for structured scaling.
Designing a UX that feels playful without obscuring control.
I’m particularly interested in feedback on:
Whether the structured + LLM hybrid approach makes sense architecturally.
How you’d approach long-term personalisation memory.
Whether narrowing to a specific segment (e.g. families or fitness users) would be smarter at this stage.
Site: https://grubl.app
Happy to answer questions about the stack, prompting, or tradeoffs.