Sensory Sprout / AI meal planning system
A system for making dinner reliable for families with selective eaters.
Most meal planning tools optimize for variety, nutrition, or discovery. Sensory Sprout starts from a different premise: for these families, dinner succeeds or fails on reliability.
See the case study
4
Adaptive conversation flows routed by eater type
1
Meal-planning reliability problem, not a generic recommendation problem
9 wks
Research, design, conversation system, and beta product built end to end
This isn’t a meal planner dressed up with AI. It’s a system designed around the conditions that actually determine whether a meal gets eaten.
I designed the product and built the conversation system from the ground up: research, interaction model, prompt architecture, evaluation logic, and trust patterns. The goal was not nutritional optimization. It was one meal, no backup plan.
Selective eating is more common and more complex than most tools assume.
Meals fail not at the category level, but at the sensory level: texture, temperature, smell, predictability, preparation, and brand specificity can all change the outcome.
Existing tools flatten these distinctions into generic likes and dislikes. That misses the real decision logic families use every day. A child may “like pasta” but reject buttered noodles if the texture is wrong, the brand changed, or the sauce touched the wrong surface.
The product needed to model food in the way these families actually experience it: not as broad preference categories, but as concrete sensory acceptance conditions.
“Dinner is not a discovery problem. It’s a reliability problem.”
That became the governing design principle for the product, the profile model, and the AI conversation system.
Profiles are assembled in stages so the system can start lean, then grow more precise over time.
Instead of demanding exhaustive setup upfront, the conversation off-ramps once it has enough signal to create a useful starting profile. From there, users can review interpretations, correct them, and accept or reject suggested updates. That keeps the system transparent while improving precision over time.
The same structure can also hold other case studies.
Use this row when you want the page to feel more like a designed portfolio system, not a one-off writeup.
If your product has a trust problem, a framing problem, or a system-design problem, that’s usually where I do my best work.
This section can act as your footer CTA. It gives the page a deliberate ending and echoes the dark band pattern from the reference site.