The system treats dinner as a reliability problem, not a discovery problem.
The hardest part wasn't generating recommendations. It was making them safe to trust.
Overview
A meal planning system for parents of middle school–aged selective eaters. The goal isn't nutritional optimization—it's reliability. One meal, no backup plan.
I designed the full product and built the AI conversation system: research, conversation design, evaluation, product design, and trust architecture. Self-initiated.
Role
PM & AI Practitioner
Team
Solo · 6 participants
Duration
9 weeks
Status
Discovery complete · Eval complete · Beta (preparing)
The problem
Mealtime can be a daily crisis, and families are left to figure it out alone.
Selective eating is both widespread and more nuanced than most tools recognize. In a typical middle school classroom of 30 kids, 6 to 9 are selective eaters. Some have a diagnosis like ARFID. Most don't. They fall into a gray area: more than "picky," but without a tool designed for them.
Most families adapt the same way: multiple meals, a shrinking rotation of "safe" foods, and constant negotiation. Dinner becomes something to manage, not something to share.
My two kids are insanely picky. I have to make 3 different meals for the 3 of us every single day — and sometimes they won't eat more than two bites. But then they want snacks every 15 minutes because they're hungry... I'm losing my mind.
Existing tools don't match the problem. Recipe apps operate at the category level. Real meals don't.
What filters capture
Likes chicken.
What families actually navigate
Tyson dino nuggets. Air-fried. From the bag, not the box. No other form of chicken.
This is the specificity gap. Generic filters collapse the details that actually determine whether a meal gets eaten. The difference between what tools store and what actually determines whether a meal gets eaten.
The impact extends beyond the child. Parents are exhausted. Siblings adapt. Meals become repetitive. Social situations become stressful.
Dinner isn't failing because families don't try. It's failing because there's no system that works at the level the problem actually exists.
Key findings & hypothesis
This isn't about expanding diets. It's about preventing collapse.
I conducted 6 semi-structured interviews with parents of children with food selectivity across a range of contexts: autism, ARFID, ADHD, and sensory processing differences. I also interviewed my daughter for a middle-school child's perspective.
The original hypothesis was straightforward: help parents expand their child's safe food list. Three interviews killed it.
These families weren't trying to grow the list. They were trying to keep it from shrinking.
Three key findings drove that reframe:
Nutrition isn't the goal. Peace is.
For families with ARFID, the core concern is that the child eats anything at all. One parent's healthcare team told her: "Just get food in him, otherwise he won't eat." These families aren't trying to optimize diets. They're trying to survive mealtimes.
Safe foods burn out, and don't come back.
"She used to love plain pasta with Alfredo sauce, and I guess I didn't make it for about a month, and then she wouldn't eat it anymore." They can't branch out because experimenting risks rejection, and they can't stay put because repetition destroys the list. Once a food burns out, it rarely returns.
Parents know what works, but don't always know why.
One parent: "I just get the feedback, not the synthesis." When I interviewed my daughter, she explained that chicken nuggets work because "the firmness of the breading keeps the stringiness away." She had never mentioned this to me before. Parents carry an enormous mental model of what their child will and won't eat — without always knowing the reasons behind it.
My initial direction was expanding food variety. That failed quickly in interviews. Parents weren’t trying to explore, they were trying to prevent regression.
Reframed hypothesis
Families need a system that slows the decay of safe foods by suggesting meals that balance predictability with just enough variation to prevent burnout.
This shifted the design problem entirely:
- Not exploration → stability
- Not variety → reliability
- Not optimization → survival (with less friction)
The system doesn't need to introduce new foods.
It needs to help families hold onto what works without breaking it.
The product
One meal. No backup plan.
Profiles are created for each family member and used together when searching for recipes. Instead of re-entering filters, parents select who they're cooking for and the system adapts results accordingly.
The system connects scattered observations—"he doesn't like mixed textures," "foods can't touch"—into patterns that meaningfully filter recipes.
Built:
- Intake survey (household, allergies, restrictions)
- Conversational assessment (four flows)
- Profile review (edit before save)
Staged:
- Recipe recommendations
- Feedback loop (ratings inform profile updates with approval)
It feels like being understood—not like using a search tool.
Intake
facts + constraints
Household, allergies, restrictions
Assessment
conversation + routing
Four flows by eating pattern
Profile
review before save
Editable foundation for personalization
Recipes
search + results + feedback
Personalization stays current over time
Product gallery
Search
Search begins with who the meal needs to work for, not just what to make.
- Mechanism: Users can search by dish or ingredient, then tailor results by selecting the family members the meal needs to work for.
- Why it matters: Personalization starts before recommendations appear, not after.
Search Results
Recommendations are personalized, but never opaque.
- Mechanism: Results reflect selected profiles and show what factors influenced matching.
- Why it matters: Users understand why something was suggested and can refine it instantly.
Assessment
Structured intake captures facts quickly and reliably. Conversation captures nuance that forms cannot.
- Mechanism: a. Form-based input handles allergies, dietary restrictions, household details, and general eating style. b. Four adaptive flows ask targeted follow-ups based on eating pattern.
- Why it matters: a. High-stakes data is captured clearly, without ambiguity or unnecessary AI interpretation. b. The system surfaces preferences parents recognize but would not necessarily think to formalize.
Profile Review
Nothing is saved without user review and control.
- Mechanism: Inputs are translated into a structured profile that users can edit before saving.
- Why it matters: Trust is reinforced before profile data drives recommendations.
Meal Ratings
The system learns over time, but only with user approval.
- Mechanism: Per-person ratings generate suggested profile updates that users can accept, edit, or reject.
- Why it matters: Personalization stays current without silently changing user data.
Design principles
Five principles shaped every decision, including what not to build
01
Meet parents where they are
Mobile-first. Recipes under 20 minutes. “I don’t know” is accepted as data. Concrete food examples teach sensory vocabulary passively. Speech-to-text reduces typing friction. Every point of friction left unresolved is an assessment that doesn’t get completed.
02
Start lean. Stay current.
Families get up and running in minutes. The profile improves from there through ratings, search behavior, and in-context edits, so personalization stays accurate without requiring ongoing maintenance.
03
Trust through transparency and control
No assumptions during assessment. Profile review before saving. Transparent recipe reasoning. Profile updates require user approval. The system acknowledges the emotional weight of the problem without turning into therapy.
04
Safety by architecture, not by policy
Recipes come from a curated database, not AI generation. Allergen safety is handled structurally, not probabilistically. A deterministic layer makes critical failure modes impossible, not just unlikely. This is what earns trust that policies alone can’t.
05
Specificity is the product
The system captures brand, preparation method, temperature, texture, and presentation at the individual level. Generic recommendations are worse than no recommendations. They erode trust faster than they save time.
System design
Personalization only works if the system can be trusted.
Trust comes from how profiles are built, how conversations are routed, and how risk is separated. Structured intake captures critical facts. Conversation captures nuance. Profiles improve through ratings, edits, and usage.
Profiles are built over time, not filled out upfront.
Structured intake captures critical facts. Conversation captures nuance. Profiles improve through ratings, edits, and usage. A profile that evolves is more valuable than one that's abandoned. A profile that evolves is more valuable than one that's abandoned.
Conversation captures what forms can't.
Conversation follows the parent's lead and asks targeted follow-ups. The conversation is the interaction design.
Different eaters require different conversations.
Four flows adapt to eating patterns. Each asks fundamentally different questions based on eating pattern — not just different depths, but different strategies.
Routing is deterministic: one classifier question before the conversation begins. No LLM inference. Wrong flow → wrong questions → unusable profile.
| Flow | Pattern | Conversation objective |
|---|---|---|
| A | Few avoidances | Spend turns on what makes meals work. |
| B | Selective with rules | Uncover cross-cutting patterns, not just food rules. |
| C | Very restrictive | Capture fragile foods, lost foods, and rejection patterns. |
| D | Limited knowledge | Accept partial input and improve the profile later. |
Separate what can fail from what can’t.
Not all failures are equal. A bad recommendation is recoverable. A missed allergen is not. The system is structured around that difference.
| Layer | If it gets it wrong | Failure cost | Tool |
|---|---|---|---|
| Recipe retrieval | Suggests an allergen | Irreversible | Deterministic database |
| Personalization | Suggests a bad recipe | Recoverable | GPT-5.2 |
| Assessment | Asks the wrong question | Adaptive | GPT-5.2 + four flows |
The highest-risk layer is the one that cannot hallucinate.
Currently Seeking
Let's build something thoughtful together.
Product roles where I can work closely with engineering and design to build custom software — including AI when it's the right tool.