I built an AI chef for my family

The hardest part at home isn't cooking, it's deciding what to eat. I built a small module that recommends tonight's dish from a photo of the fridge. A development note for something not yet shipped.

I built an AI chef for my family

This feature isn’t shipped yet. I’m writing it down partly to keep a record for myself, and partly hoping someone can point out problems I haven’t thought of.

Why I started

The most draining thing in my home every day isn’t cooking, it’s deciding what to eat.

The essence of this problem is decision fatigue. You’ve worked a full day, stand in front of the fridge, and inside there are eggs, tomatoes, half a cabbage — and you have to give an answer in thirty seconds that nobody objects to. The difficulty of this task is badly underestimated: it’s not “pick a dish,” but simultaneously satisfying hidden constraints like ingredient inventory, the family’s tastes, today’s weather, cooking time, and “we already had this yesterday.”

Recipe apps on the market can’t solve this. They think like a search engine: you type a dish name, they give you a recipe. But my problem was never “how to make braised pork,” but “what can I make with what I have in my hands.”

So this module solves the stretch from inventory to decision, not recipe teaching.

What it looks like

It’s built as a chat interface. Open it and there’s an AI conversation with a status line up top: “Your personal chef · online.”

Below are a few quick-entry buttons for the highest-frequency questions:

  • I have eggs and tomatoes in the fridge, recommend a dish
  • I feel like something spicy today
  • Help me plan this week’s dinners
  • Recommend a light home-style dish

Next to the input box is an upload button where you can directly photograph the fridge or the ingredients. This is the most worthwhile interaction to build — because the act of “naming the ingredients” is itself tiring; you have to know what’s at home before you can say it. Taking a photo is far more natural than having the user type out a list.

A few key design decisions

Why chat, not a form?

At first I wanted a form: pick ingredients, pick taste, click recommend. I abandoned it after the prototype. The problem with a form is it forces the user to structure their need, while the core of “what to eat today” is precisely that you don’t know what you want either. The benefit of chat is the user can be vague — an input like “just something spicy” can’t be expressed in a form.

The cost is more conversation turns and higher token consumption. More on that later.

Why build a “taste preference” setting?

The UI has a hint: “Your chef isn’t built yet — tap here to set taste preferences.”

I didn’t plan this at first. The model itself knows what “light” or “spicy” means, but after building it I found it was wrong — the model knows “light in the general sense,” not light in your household. Some homes’ “light” means no chili; others’ means low oil but with a wok hei (seared aroma).

This preference setting is essentially building a very light profile for each family. It’s only a few fields, but it decides whether the recommendation feels “like your family’s cooking.”

Why limit to 20 per day?

The UI shows “Remaining today 20/20.” That number isn’t random.

The problem with chat-style interaction is uncontrolled cost. The user can ask endlessly — “give me another,” “is this too salty,” “my son doesn’t eat cilantro.” Every follow-up is a model call, and it has to carry the prior context. 20/day is the number I calculated to be both not noticeably harming the experience and keeping per-user cost within an acceptable range.

If after launch I find 20 doesn’t cap real users, it means my estimate of usage frequency was wrong, and I’ll adjust.

Unsolved problems

I’ll write a few I’m still unsure about; if anyone who’s done something similar sees this, I’d appreciate the input.

One, recognition accuracy. Recognizing ingredients from a photo is fine for common ones (eggs, tomatoes, cabbage), but recognition drops for leftovers in a storage box deep in the fridge, or unopened seasoning packets. If it misrecognizes and then recommends based on wrong info, the user’s trust collapses instantly. One current idea is to show recognition results to the user for confirmation first, but that adds a step, contradicting the “just take one photo” intent.

Two, recommendation homogenization. LLM dish recommendations have an annoying tendency: no matter how you ask, it leans toward recommending the few most common home dishes. Tomato-and-egg shows up repeatedly in some form. Pure prompt constraints have limited effect; probably need to introduce some randomness or a dedup pass.

Three, the positioning of the weekly-dinner-planning feature. “Help me plan this week’s dinners” sounds great, but a real family’s week is interrupted by all sorts of emergencies — overtime today, guests tomorrow, the kid says they want fried chicken the day after. No matter how good the plan, it’s void by the next day. Should this be “generate seven days at once,” or “adjust daily based on remaining ingredients and what was eaten before”? I haven’t figured it out. The latter is smarter, but also more expensive and harder to get right.

Next

The features are basically complete, stuck on the final round of polish before launch. After launch I’ll write a follow-up with real user feedback, cost data, and usage frequency — especially whether that “20 per day” assumption was right.

If you’re also building something similar (ingredient recognition, recipe recommendation, household LLM applications), feel free to reach out; my WeChat ID is on the about page.

Qimiaogan This work is licensed under CC BY-NC-SA. Please credit the source and author when reposting.

Contents