Predicting whether a meal will be accepted before it reaches the table
Most meal planning tools help families discover meals. Sensory Sprout helps families avoid meals likely to fail under real household conditions.
Meal viability before selection. The system evaluates meals against household constraints before they are shown, instead of relying on broad preferences after selection.
Families managing restrictive eating do not need more recipes. They need meals that survive real conditions.
Why this is a product, not just a concept
Families managing restrictive eating do not struggle to find meals. They struggle to get through them.
Existing tools optimize for discovery: recipe apps help users browse, and meal planners help organize choices. But neither can answer the question that actually matters: will this meal work tonight?
Sensory Sprout addresses this gap by treating meal acceptance as a reliability problem, not a discovery problem. The product evaluates whether a meal is likely to work before families invest time, effort, and expectation into it.
LLMs can help structure messy household inputs, while lightweight feedback loops can learn from confirmed outcomes instead of assumptions.
I led product definition and system design: problem framing, research synthesis, acceptance modeling, interaction direction, and prototype decisions.
Meal planning breaks when preferences diverge
Tools optimize for choosing meals
Most meal tools assume one good option will work. They help families browse recipes, filter ingredients, and choose what to cook.
In households with restrictive eating, choosing a meal is not the hardest part. A meal that looks viable can still fail when preparation, texture, temperature, or context does not match what each person can accept.
Broad preferences are too coarse to predict acceptance. The system needs to model conditions, not ingredients alone.
What tools store
“She likes chicken.”
What actually determines whether a meal works
“She likes Tyson dino nuggets from the bag, air-fried, crispy, and hot. She refuses chicken prepared any other way.”
Why recommendation systems still fail
“Child likes chicken”
→ recommends baked chicken tacos
- Tortillas feel inconsistent
- Shredded chicken texture varies
- Toppings introduce uncertainty
- Temperature changes during assembly
The issue was never the ingredient itself.
Before parents could worry about nutrition, they had to solve for acceptance
Meals do not fail at selection. They fail at the table.
Parents were not struggling to find meals. They were struggling to get through them. Small differences in texture, temperature, preparation, and presentation determined whether a meal was accepted or rejected.
The research shifted the product from cataloging preferences to identifying the conditions that make eating possible.
Safe foods were often temporary, situational, and easily disrupted. Parents optimized for predictability before nutrition. Familiar ingredients did not guarantee acceptance if texture, preparation, or presentation changed unexpectedly.
I microwaved her plain Alfredo pasta and the sauce at the edge turned slightly brown. She wouldn’t eat it.
Parent of a child with ARFID
I know what’s in the frozen burrito. With other burritos, sometimes you don’t know what’s in them.
11-year-old participant
6 parent interviews · 1 child interview · community discussion review
Rejected meals created cascading stress for the entire household
A failed meal was rarely just a failed meal
Parents described backup meals, emotional negotiation, separate preparation, uncertainty about whether a safe food would still feel safe, and the exhaustion of managing reactions night after night.
Meals could fail because they were plated differently than expected, cooled too quickly, or introduced an unfamiliar variation.
The challenge was not simply finding food a child liked. It was reducing the likelihood of stress, waste, conflict, and unpredictability at the table.
The product needed to protect effort before dinner was made, not only respond after a meal failed.
Reliability depended on making hidden household conditions explicit enough to evaluate before families committed time and expectation.
Meals worked only when five forces stayed in balance
Reliable meals depended on balancing multiple household realities simultaneously: enough familiarity to feel safe, enough variation to prevent routines from narrowing, and enough practicality for parents to sustain over time.
Reliable meals, controlled variation
Meal viability depends on the relationship between needs and constraints.
Predictability
Must feel familiar enough to avoid rejection.
Variation
Introduce change without shrinking safe foods.
Sensory tolerance
Texture, temperature, and prep determine viability.
Parent effort
Must be realistic to prepare and serve.
Table dynamics
Must work socially, not just nutritionally.
The goal was not discovery. It was acceptance.
Families needed meals to work under real conditions, using what they already knew was safe. This shifted the system from recommending options to evaluating viability.
The product adapts around household realities instead of assuming stable preferences
Families needed the system to learn carefully, not aggressively
To support meal reliability, the product captures the conditions that make meals feel safe, filters out meals unlikely to work, learns from what happens at the table, and updates only after families confirm the outcome.
Acceptance modeling prevents recommendation from becoming guesswork.
Capture what makes meals feel safe
Collect household rules, safe foods, disliked conditions, and contextual details.
Translate household patterns into meal rules
Turn messy qualitative inputs into explicit conditions a meal must satisfy.
Filter out meals unlikely to work
Reduce false hope before families commit time and effort.
Understand what happened at the table
Learn whether the meal was accepted, adapted, refused, or replaced.
Update only after family confirmation
Change the profile only when the family confirms the pattern.
Each decision reduced the risk of turning dinner into another failed experiment
Filter out meals unlikely to work before discovery
Problem If evaluation happens after selection, families can still spend time, energy, and expectation on meals that appear viable but fail in practice.
Decision Filter out meals unlikely to work against household constraints before results are shown.
Tradeoff Reduces open-ended variety and makes the experience less exploratory.
Impact Protects parent effort by surfacing meals that are more likely to work at the table.
Translate household patterns into meal rules instead of inferred preferences
Problem Preferences are too vague to predict acceptance. Small changes in preparation, texture, temperature, or presentation can change whether a meal feels possible.
Decision Translate implicit household rules into explicit conditions a meal must satisfy.
Tradeoff Requires more detailed intake and a clearer explanation of why meals are filtered.
Impact Makes acceptance reasoning visible instead of relying on broad preference inference.
Update only after family confirmation before updating the system
Problem If the system learns from assumed outcomes, it can reinforce the wrong patterns and destabilize routines families rely on.
Decision Require family confirmation before updating a profile or treating a pattern as true.
Tradeoff Adds small moments of friction after meals.
Impact Prevents premature generalization and keeps families in control of what the system learns.
The interface helps families understand why a meal is likely to work
The product shifts from generating options to explaining fit
Value comes from helping families understand why a meal appears safe enough to try, not simply suggesting more meals that might work.
The interface makes the acceptance logic visible so parents can judge whether the system understood the household correctly.
- Matches known safe texture
- Uses familiar preparation style
- Introduces only one new variable
- Avoids conflicting sensory triggers
The system should not learn faster than the family can trust it.
The MVP is focused on validating reliability, not expanding features
Validated need
Families need acceptance support, not more discovery.
Defined product model
The product direction is a structured acceptance model for meal reliability.
Active risk
Prediction accuracy must be validated across households before scaling.
The next product risk is not whether AI can generate meal ideas. It is whether the system can evaluate household-specific viability accurately enough for families to rely on it.
Reliability matters differently when failure is emotionally expensive
What changed in my thinking
I started with a meal planning problem. The work revealed a reliability problem.
In most meal apps, a bad recommendation is a minor inconvenience. For these families, it can mean stress, wasted effort, conflict, or losing trust in a fragile routine.
The product needed to treat those consequences with care. That meant making uncertainty visible, learning cautiously, and resisting the temptation to over-generalize from incomplete signals.
Decision-level lesson: The more emotionally expensive the consequence, the more carefully the product has to separate suggestion, evaluation, and confirmed learning.