No more grocery shopping
I do not dislike cooking. I dislike having to mandatorily do it (not even AI will spare us from eating every day) and the whole loop around it: decide what to eat, turn that into a list, go to the shop, carry it home, only to discover a few days after that I forgot one of the key ingredients. Preparing your lunch can be fun, but it is not (for me) if I have to do it every day.
So the goal is not a better shopping trip. It is no shopping trip. This post is the plan, written before any of it works, so that later I can be honest about which parts of it were wrong or not plausible.
The scenario to solve
Decide → list → buy → transport → cook.
I want to fully automate the process, from deciding what to purchase, to how and when to cook each meal. Thinking what to eat every day becomes annoying, and what’s worse, it gets really boring. By doing this I not only want to save some time, but also learn new recipes and try food that I would possibly never think about cooking on my own. I want to save my creative energy for tasks that will make me fill more fulfilled.
It’s worth separating the decisions from the errands, because they fail differently. The deciding stage is genuinely hard and genuinely repetitive, which is where AI is useful. The buying stage is the one everyone assumes is a solved API call, and isn’t.
Phase 0 — Defining the requirements
- I need to be able to redefine menu/purchasing criteria → I currently live on my own with some sporadic visits, but if that ever changes, temporarily or permanently, I need to be able to redefine the purchasing criteria as well as the dietary restrictions.
- I currently track my monthly expenses so doing this should not change significantly my food expenses. I will also not tolerate any food waste. I’ll instruct AI to buy seasoning and food that can be reused over multiple dishes before any of it expires. Having to throw food away would be a disaster. I need a way to stop the automation (in case I manage to automate the whole flow) to introduce corrections and/or if I see I’ll need more time to consume what’s been purchased, for whatever reason (there’s weeks where I eat out more, I consumed less calories that week…).
- I’m not a simple person. I do a lot of sports, and my stomach is somewhat delicate, so my diet is quite regular, and revolves around strict criteria. AI needs to be able to rotate menus without skipping my dietary needs (that, as mentioned above, can change).
- I work remote, so I can allow some time to cook my fresh meal every day. In a second phase, I can consider batch cooking but for now that will be a to do. However, I do have time limitations on my cooking. I can’t be actively cooking more than 20 minutes. This doesn’t mean I can’t cook something that takes longer than that (e.g to boil) but I can’t be checking on it actively for more than 20 minutes. 20 minutes + 40 to eat is the break I can reasonably take off my daily work.
Phase 0.5 — Defining the inputs
These are the required variables to input that can vary over time.
- Dietary restrictions (food I can’t eat, food I dislike, calories and nutrient distribution)
- Cost per week
- Maximum cook time on a weekday
- How often a repeat is OK
- Day to order food / time to receive the order
Let’s discuss now all the different steps and caveats I need to take into account:
Phase 1 — menu generation
The output is a week of meals and a consolidated shopping list where every item traces back to a recipe.
That tracing is the part that matters. A list I can’t explain to myself is a list I’ll second-guess, and second-guessing is precisely the thing I’m trying to delete. It also handles the arithmetic: one bunch of parsley serves three meals, and working that out is not how I want to spend a Sunday.
The hard problem here isn’t generating a menu. It’s memory — the system has to know that what it suggested three weeks ago was a failure, and not suggest it again.
Phase 2 — buying, where the plan has to be honest
The comfortable assumption is that “submit the basket” is an API call. Mostly, it isn’t. Supermarket ordering is a website built for people, and driving it programmatically is fragile, and quite possibly against terms I already agreed to.
So before any code gets written for this stage, the question to answer per retailer is: is there a documented API or partner integration, does the app expose anything stable, and what do the terms actually permit? I’d much rather learn that the answer is “no public interface, so this step stays manual” than build something that breaks every time a button moves.
And the fallback is still a win. If the system assembles a basket that I review and submit with one tap, that has already deleted the trip, the list and the arithmetic, and left me with one button. Full automation of this stage is the nice-to-have, not the point.
Phase 3 — paying, which gets the tightest constraints
This is the only step that can carry some risk, so it’s the only one I’m carefully designing from the start.
- A dedicated payment method with a hard cap.
- A per-order spending limit, where exceeding it means refusing and asking, not retrying.
- An approval step before each week’s charge, at least until the thing has earned some trust.
- A log of every order with totals and line items, so a wrong order is something I notice the same day rather than at the end of the month.
Picking the delivery slot is the easy half: take the available windows, prefer the usual weekday, done.
Phase 4 — the recipes have to arrive where I cook
Recipes need to be available in my phone or tablet, so I can open them and read through when the time for cooking comes.
Step two — someone else cooks
Software stops here. The second half of the plan is a person who arrives after the delivery and cooks.
The difficulty isn’t the hiring, it’s the coupling. The cook’s arrival is downstream of a delivery window I don’t control. A late delivery means someone standing outside my door for half an hour. So the schedule needs slack built in, and the system needs to tell them when the delivery actually arrived, not when it was promised.
I will have to wait and understand how predictable and trustable the system is, and then start thinking about this phase. I know there’s companies that offer part time chefs that will come into your house and batch cook in 3-4 hours your whole week’s meal. But I still need to do a lot of research on that.
How I’ll know it worked
- Zero unplanned supermarket trips in a month.
- Under fifteen minutes of my attention per week.
- No order I didn’t want.
- Less food thrown away than now.
The code lives in its own repo. I will keep this post updated with the implementation details, and the retrospective when parts of this turn out to be wrong.