Sensory Sprout
For these families, divergence is the norm.
A system for making dinner reliable for families with selective eaters
This isn’t a meal planner. It’s a system for making dinner reliable.
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.
Overview
I designed the full product and built the AI conversation system underneath it: research, conversation design, evaluation, product design, and trust architecture. Self-initiated.
Key insight
The hardest part wasn’t generating recommendations. It was making them safe to trust.
Activities led
User research · Conversation design · Prompt engineering · Evaluation · High-fidelity product design · Trust architecture
Product arc
Research → assessment design → system architecture → evaluation → beta prep
Role
PM & AI Practitioner
Team
Solo · 6 research participants
Duration
9 weeks
Status
- Discovery complete
- Eval complete
- Beta (preparing)
assessment iterations before production code
distinct strategies by eating pattern
The problem
Dinner is a daily negotiation with no reliable system.
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.
“I have to make 3 different meals every night … and sometimes they won’t eat more than two bites.”
Anonymous post from a local mom’s Facebook group
The tools that exist 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. 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.
The reframe
This isn’t about expanding diets. It’s about preventing collapse.
6 interviews reframed the problem completely. The original assumption was straightforward: help parents expand a child’s safe food list. But that’s not what these families are trying to do.
They’re trying to keep the list from shrinking. Safe foods burn out. Experimentation is risky. Repetition is fragile.
“She used to eat this all the time. Then one day, she just wouldn’t.”
Nutrition isn’t the primary goal. Eating anything is.
“Just get food in him.”
This shifts the design problem entirely: not exploration, but stability; not variety, but reliability; not optimization, but survival with less friction.
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.
-
The goal isn’t better nutrition. It’s getting through dinner.
Parents are trying to reduce conflict and keep meals workable, not engineer ideal diets.
Design implicationDesign for family reliability, not behavior change.
-
Safe foods burn out, and often don’t come back.
Families can’t branch out easily, but they also can’t stay static forever.
Design implicationSupport variation inside what already works.
-
Parents know what works, but don’t always know why.
The most useful rules are often buried in tacit knowledge: texture, preparation, temperature, presentation.
Design implicationUse targeted prompts to surface richer, more relevant data.
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 each time, 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.
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
Built: intake survey, conversational assessment, and profile review. Staged for beta: recipe recommendations and the feedback loop that suggests profile updates with user approval.
It feels like being understood—not like using a search tool.
Search screen
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.
Intake survey
Structured intake captures facts quickly and reliably.
- Mechanism: Form-based input handles allergies, dietary restrictions, household details, and general eating style.
- Why it matters: High-stakes data is captured clearly, without unnecessary AI interpretation.
Conversational assessment
Conversation captures nuance that forms cannot.
- Mechanism: Four adaptive flows ask targeted follow-ups based on eating pattern.
- Why it matters: 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.
Recipe detail
Personalization carries through to the recipe itself.
- Mechanism: Inline callouts show how the recipe adapts for each selected person.
- Why it matters: The system supports one shared meal while respecting individual needs.
Meal ratings + feedback loop
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
Designed for reliability, not optimization.
Meet parents where they are
Mobile-first. Recipes under 20 minutes. “I don’t know” is valid input. Speech-to-text reduces friction.
If the assessment feels like work, it doesn’t get completed.Start lean. Stay current.
Profiles don’t need to be complete to be useful. They need to be usable, then improve through ratings, edits, and usage.
A profile that evolves is more valuable than one that’s abandoned.Trust through visibility and control
Profiles are reviewed before saving. Updates require approval. Users can edit at any time.
Nothing enters the system without the user seeing it.Safety by architecture, not policy
Recipes come from a deterministic database. AI does not generate meals. Allergen risk is handled structurally, not probabilistically.
Critical failures are made impossible, not unlikely.Specificity is the product
Preferences are constraints: brand, texture, preparation, temperature, presentation. Generic recommendations erode trust faster than they save time.
If it’s not specific, it’s not useful.System design
Personalization only works if the system can be trusted.
The system isn’t built around generating recipes. It’s built around making personalization reliable in a high-stakes domain.
Profiles are built over time, not filled out upfront.
A static form can’t capture what these families need. Structured intake captures critical facts; conversation captures nuance that can’t be anticipated. Profiles improve through ratings, edits, and small additions made in context.
A profile that evolves is more valuable than one that’s abandoned.
Conversation captures what forms can’t.
The challenge wasn’t collecting more data. It was collecting the right data without overwhelming the user. Conversation follows the parent’s lead, asks targeted follow-ups, and surfaces patterns parents recognize but don’t explicitly name.
The conversation isn’t input. It’s the interaction design.
Different eaters require different conversations.
A single conversation model produced inconsistent and often useless profiles. The issue wasn’t depth. It was strategy.
| 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. |
Routing happens before the conversation begins: one classifier question, deterministic logic, no LLM inference. Wrong flow means wrong questions, which means an unusable profile.
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.
Evaluation
Non-deterministic systems require structured evaluation.
The system cannot be validated through spot checks. The same input produces different outputs. “Good” varies by context. Errors compound across turns.
Evaluation had to measure decision quality, not just output quality.
Eval at a glance
A three-tier framework caught failures before users did.
Tier 1: 40 single-turn synthetic test cases across 10 archetypes. Tier 2: 3 multi-turn scenarios plus 4 edge cases. Tier 3: 20–30 automated conversations in Replit + Langfuse, planned for beta.
The primary criterion was simple: did the model pick the highest-value next move for recipe success? A perfectly formatted response with the wrong follow-up is still a failure.
Prompt architecture mattered more than model upgrades.
Upgrading the model alone improved a small number of cases. Restructuring the prompt improved more than twice as many. The limiting factor wasn’t model capability. It was decision structure.
Multi-turn testing exposed structural failures.
Single-turn tests passed cases that failed in conversation. Three failures only appeared across turns: no stopping condition, cross-flow contamination, and inefficient probing.
| Failure mode | Observed behavior | Structural fix |
|---|---|---|
| No stopping condition | Conversations ran 11+ turns when 3–4 were sufficient. | Explicit stop rules by flow. |
| Cross-flow contamination | Strategies from one eater type appeared in another. | Split into four flow-specific agents. |
| Inefficient probing | The model went food-by-food instead of identifying patterns. | Ranked decision tree + explicit objective selection. |
Cost was negligible. Trust was not. One incorrect profile breaks trust with this audience.
The system succeeds or fails on what it does next.
What this taught me
Reliability comes from constraints, not capability.
Separate layers by failure cost. Structural problems require structural fixes.
The system works not because the AI is more capable, but because the highest-risk parts are constrained by design.