meal-planner
Picks a week of meals against nutrition targets and a budget, then fills a grocery cart with the result.
Working, with a loading pipeline behind it and a live store integration.
Solved, not sampled
A week of meals that hits macro targets, stays inside a budget, and does not repeat itself is a constraint problem, not a shuffle of a recipe list. Picking randomly and hoping produces a plan that satisfies the targets on average and no individual day.
Behind the solver is a loading pipeline that does the unglamorous half: parsing ingredient text, normalising the names that mean the same thing, tagging recipes, working out equipment and difficulty. Each of those stages is separately tested, because a solver fed bad ingredient data produces a confident and wrong plan.
The last mile is the awkward one
Turning solver output into a filled cart means matching an ingredient to a real product in a real store, and store search is adversarial: the top results are frequently unlabelled ads for something else entirely.
Matching therefore works from the head noun of the ingredient rather than trusting result order, which is the difference between buying rice and buying whatever the store was paid to show above the rice.