Home Meal Planner: local AI for my wife’s weekly meals

Desislav Ivanov — Mon, 05 Oct 2026 04:06:53 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend.

What I Built

I built Home Meal Planner for my wife in Sofia, Bulgaria.

The goal was practical: turn recipes into a weekly plan, then turn that plan into a shopping list we can actually use.

A recipe might need 400 grams of tomatoes, but the shop sells cans, bags, or products priced by the kilogram. Planning several meals adds another problem: combining those ingredients without losing quantities, preparation details, or brand preferences.

Home Meal Planner brings that workflow together:

Save a recipe manually or import it from a URL.
Review and correct the imported ingredients.
Build a meal plan with editable suggestions from a local Gemma model.
Scale and consolidate the ingredients.
Compare product offers from grocery stores.
Select products and open shopping lists grouped by store.

The application supports Bulgarian and English ingredient text. It is designed for one household, with private access and a small collection of familiar recipes.

The final shopping decision stays with the person using it. Each selected product has an external link for manually adding it to the store’s basket.

Demo

Watch the demo on YouTube.

The recording shows recipe import and editing, weekly planning, meal suggestions, ingredient consolidation, product comparison, selection, and shopping lists split between stores. It ends by opening a real product page.

One concrete example is package calculation: if the plan requires 1,200 grams of tomatoes and an offer contains 400 grams per can, the application calculates three cans and their total purchase cost.

That matters more than simply displaying the cheapest package.

Code

Home Meal Planner on GitHub

The repository includes setup instructions, regression tests, store validation scripts, and a deterministic fixture mode for repeatable demonstrations.

The live store validation report records public product retrieval from VMV and Randi. Other candidate stores remain outside the working live scope until their adapters can retrieve usable offers reliably.

How I Built It

The application is a TypeScript monorepo with:

React and Vite for the interface.
Fastify for the API.
Shared Zod schemas for application contracts and AI responses.
Mastra for the meal-planning agent.
Gemma 4 E4B, running through Ollama’s OpenAI-compatible API.
Local JSON persistence for the competition MVP.

Gemma receives the saved recipe collection and the current plan. It proposes recipe choices and short explanations.

The application validates the response before using it: recipe IDs must exist, dates must belong to the plan, and suggestions must not overlap meals already selected. Additional planning rules favor suitable meal slots and balance recipe repetition. The user reviews suggestions before applying them.

If the model is unavailable or returns invalid output, a deterministic planner keeps the workflow usable.

To verify the actual model integration, I ran the strict live smoke test on October 5 using local gemma4:e4b, Mastra, and synthetic Bulgarian recipe data. The test passed, and its final output contained 21 validated meal suggestions after the application’s planning rules were applied.

This test fails on model errors instead of accepting the fixture fallback. The command, configuration, and successful terminal output are recorded in the Gemma and Mastra live test evidence.

Ingredient scaling, unit conversion, package counts, ranking, and totals are calculated in application code.

Offers show their data provenance and availability. Compatible offers can be compared by the cost of buying the required quantity, including excess caused by package sizes. Exact-brand matches and alternatives are distinguished.

Store prices are snapshots. Product subtotals do not include delivery fees or guarantee the final checkout price.

Why Does Open Innovation Matter?

Running an open-weight model locally makes this project approachable as a household tool.

Meal-planning requests go to the local Ollama endpoint, without requiring a hosted model API key. Mastra provides an open-source agent layer, while shared schemas make the boundary between model output and application behavior explicit.

The model integration can be changed independently of the shopping calculations. Store adapters can also be extended as access and product data improve.

For this project, open innovation means being able to inspect and adapt the tool around a real household’s recipes and shopping habits.

Live store comparisons still require internet access. Fixture mode provides a separate, repeatable way to test the workflow offline.

What I Learned and What Comes Next

The difficult parts were interpreting recipe data and deciding whether a store result represents the ingredient the household needs.

Recipe quantities, units, and yields need review. Store keyword searches can also return irrelevant products. The demo exposes both of these MVP limits, so tighter product-category filtering and clearer import corrections are the next priorities.

The next useful test is handing the tool to my wife and watching where she needs help. That feedback will guide whether it needs fewer steps, clearer quantities, or better product suggestions.

I have not measured time savings yet. The aim is to make the weekly planning and shopping process easier enough that she chooses to use it again.

Prize Categories

Best Use of Gemma

Gemma 4 E4B runs locally through Ollama and proposes editable meal suggestions using the household’s saved recipes. Structured validation and application rules control how those suggestions enter the plan. The repository includes evidence of a successful strict live test.

Best Use of Mastra

Mastra supplies the agent configuration and structured generation layer connecting the local model to the meal-planning workflow. The same live test exercises the Mastra agent, local inference endpoint, and response validation.

DEV Community: Desislav Ivanov