Defer food recognition
A tap-based list preserved food selection without a recognition model, training pipeline, or recognition-error handling.
Trade-off: Less automation for the user; fewer dependencies to build and validate.
Making unfamiliar food
worth exploring.
For parents, introducing a new food can mean another mealtime negotiation. I built Nutrizle to give children a reason to be curious, connecting character-led play with practical recipes and shared activities.
Product ManagerProduct Owner
Product strategy, MVP prioritisation, AI prototyping, and end-to-end delivery. Independently led over two years.
Product + research
Mealtimes put the burden on parents.
Parents carry two jobs at mealtimes: deciding what to prepare and persuading a child to try it. A recipe solves the first. It does little for a child who rejects an unfamiliar ingredient.
I focused the product on the missing connection: build interest through food characters, then give parents a practical way to turn that interest into a meal or shared activity.
For the child
Build curiosity through play.
For the parent
Turn that curiosity into everyday meals.
Shared characters.
Different jobs.
01 / 02
Explore the current app in a web demo. Your changes reset on restart. Camera AR and device-only features require the installed app.
Choose the characters children respond to.
User preference outweighed the investment already made.
I had invested significantly in commissioned characters. Before committing to the visual direction, I compared them with AI-generated alternatives in a preference test with 50 children in Mannheim.
94% preferred the AI-generated characters. I changed direction. Child appeal mattered more than protecting the investment already made.
The cost was reworking a consistent character system across the app, books, and AR. The test supported this visual choice; repeat use remained a separate question.
Character preference · Mannheim
94% preferred AI-generated50 children
Strategy
Prioritise the family experience over feature breadth.
I kept the launch focused on the family experience and removed infrastructure that did not need to be on its critical path.
One mobile foundation
A shared React Native / Expo codebase concentrated effort on the experience, rather than two native implementations.
Trade-off: a smaller maintenance surface, with device-specific testing still required.
Let the books open AR
QR codes and existing device viewers connected physical books to AR without a custom engine.
Trade-off: Less control over the AR experience and dependence on device support.
A book opens the door.
AR brings the character into the room.
I connected the physical and digital product through QR-based AR. The same character world carries across books, the app, and the web.
Explore the Nutrizle website ↗
How I owned release quality
Separate routine access from sensitive actions
I removed the repeated arithmetic question at the entrance to Parents mode. It interrupted everyday tasks such as recipe browsing and meal planning. I treated purchases, account actions, and external links as separate protection requirements rather than using a blanket barrier around the parent experience.
Restore a reliable path through meal planning
A parent could become trapped between a recipe category and its filter screen. I treated this as a broken journey, not a back-button defect. The navigation flow was corrected, and the related meal-plan flow was checked for the same failure pattern.
Expand coverage when device testing exposes a gap
Installed Android builds revealed clipped content and unreachable controls that were invisible in the browser preview. I expanded verification to nine phone and tablet frames with realistic system-bar spacing. Full tablet navigation remained a separate open item.
AI product judgment
Design AI generation for consistency and cost control.
Story engine: working prototype
Not integrated into the launch app.
I chose reusable story modules over generating an entirely new story for every child. Fixed character context made the input inspectable; modular assembly reduced repeated model calls.
Change the cast.
See the story assemble.
Select food friends to include in the story.
Interactive demonstration using saved prototype outputs. No live generation or personal data.
The assembled story
Controlled context
Explicit character lookup keeps the model’s input inspectable. No vector database was needed for a small, fixed canon.
Reuse, with a trade-off
Shared modules reduce repeated generation. The cost is less individual variation and more attention to transitions.
How I evaluated content and corrected a false positive
I developed an editorial checker to flag wording, pacing, and continuity issues for human review. Its usefulness depended on catching real problems without rejecting valid storytelling.
The checker interpreted “a golden glow” as the named power “Golden Glow” and incorrectly flagged a character using another character’s power.
I refined the rule to distinguish a named power from ordinary prose, then checked both cases. The legitimate phrase was no longer blocked; the known example of a character using the wrong power was still caught.
Trust + quality
Make nutrition claims traceable before publication.
Nutrition content needs traceable evidence, not just plausible wording. I separated source values, claim calculations, and editorial approval in a read-only knowledge graph.
Missing verification must block approval.
An unimplemented medical-claim check was returning “false,” making missing verification look like a pass. I required an explicit “unimplemented” state that could not authorise publication.
Before
Not implemented → looked clear
After
Not implemented → not publishable
Explore the evidence behind a recipe
Open the graph in a full window ↗Historical pre-launch inspection view. These counts describe that snapshot, not the current release. The tool supports review; this case study does not establish final claim clearance.
What remained unresolved before publication
- 107 unresolved source differences
- Kept visible for source reconciliation rather than silently resolved.
- 27 claim wordings still unverified
- Separated wording review from the underlying nutrient calculation.
- 56 development-only authorisations
- These development-only authorisations did not permit publication in the recorded snapshot.
How I used AI
AI sped delivery. I kept the product decisions.
I used role-based AI assistants for research, drafts, and review. Product direction and release decisions stayed with me — a draft is never a publish. The point of the practice is inspectable handoffs, not autonomous shipping.
A high-level view of the internal AI workspace that supported delivery — role cards and shared work, under my approval.
View screenshot at full size ↗
Static view. The interactive 3D studio appears when the page is served over the web.
A studio, not a chatbot.
An interactive view of specialist AI roles that supported the work. Assistants, not headcount.
Define the task before delegating
I define the outcome and constraints first, then assign the task to a specialist role and review the result against the brief before anything moves forward.
Trade-off: One more step, in exchange for consistent routing and clearer boundaries between roles.
Separate drafting from publication
Support replies and content drafts enter a review workflow. Producing a draft does not authorise sending or publishing it. I retain the final editorial decision.
Trade-off: Slower publishing loop; a much lower risk of an unreviewed message going out.
Keep nutrition evidence separate from generated text
Nutrition claims stay tied to inspectable source values and calculations. Pulling context into a task is not the same as verifying a claim — editorial approval still required.
Trade-off: source records and review rules need maintenance; generated wording still needs editorial review.
Keep internal tools separate from the family product
Bot Studio supports my internal work. It is separate from the shipped family app, and the story-generation prototype is not part of the launch experience.
Trade-off: new AI capabilities can be evaluated internally before deciding whether they belong in the family experience.
Internal studio practice · integration details in the case notes
Clear ownership, controlled actions, traceable work.
I kept AI support inspectable: work stays traceable, higher-risk actions need my approval, and activity is never counted as business impact.
- 01
Make the work traceable
Keep a short trail of what was asked, decided, and why — so handoffs stay reviewable without depending on chat memory.
- 02
Approve before acting
Routine support can proceed within limits I set; higher-risk changes wait for my approval before they run.
- 03
Keep context with the task
Bring the brief and prior decisions into the task so review is based on evidence, not chat memory.
- 04
Bound autonomy, then escalate
Assistants work within limits and escalate when approval, judgment, or a stop is needed — they do not chain work on their own.
- 05
Do not invent outcomes
Separate activity from outcomes. Missing data stays missing — Completed jobs are not hours saved or attributed revenue.
How work moves
Brief → draft → my review → approve or revise → only then publish or act
Product work stays on the delivery board. AI support runs under my account and my approval — it does not create a parallel ownership model.
What is built, and what still needs validation
What I can stand behind here: approval boundaries and a review trail for AI-assisted work. Live integration checks and business-outcome attribution are still open. This chapter documents practice, not proven commercial impact.
Launch outlook
Learn from a focused live product.
The app is live. The next question is whether character appeal becomes a repeat family habit, and whether parents find enough practical value to keep using it.
Launch preparation
Bilingual mobile product, website, book-to-AR assets, published books, and a separate claim-checking tool.
Prototyped
AI story generation with controlled character context and reusable narrative modules. Not integrated into the launch app.
Next validation priorities
Repeat family use, practical value for parents, and willingness to pay for continued content.
Commercial assumptions to validate
The commercial direction combines free entry, paid content, and books as a bridge between offline discovery and digital use. Willingness to pay and repeat family use remain the key assumptions to validate before expanding the offer.