Rule out the AI-toy pattern first
The fastest version of this idea is a chatbot toy. Regulatory and trust research made clear that was the wrong shape for a product touching kids.
Case study · Parent-mediated AI storytelling
ToyTrail turns shipping into storytelling.
Safe story infrastructure for toy brands. ToyTrail turns the post-purchase shipping window into a personalized story adventure tied to a physical toy, then extends the relationship through a parent-approved subscription. It is deliberately not an AI toy or a child-facing chatbot.
STATUSResearch-complete PRD · web + mobile prototype
ROLEProduct research, full-stack build, AI vendor due diligence
STACKCloudflare Workers · Hono · React · Expo
TOYTRAIL · SNAPSHOT
7WEB SURFACES
2PLATFORMS · WEB+MOBILE
0CHILD-FACING CHATBOTS
- Landing, activation, parent portal, review queue, reader & gallery
- Consent settings and a merchant dashboard, built parent-first
- Cloudflare Workers + Hono backend, React web app, Expo mobile parent app
- Claude for story planning/drafting behind a provider-abstracted image pipeline
Problem
The moment a toy ships, the relationship with the brand goes quiet.
A toy purchase ends with a box arriving. There is no next moment, no reason to open an app, no ongoing relationship between the brand and the family beyond word-of-mouth.
ToyTrail treats that shipping window as the opportunity: a parent-approved story tied specifically to the toy that just arrived, with a deliberate decision to keep the AI in a parent-mediated, non-conversational role.
PRODUCT LOOP
The parent is the product, not the middleman.
Every step in the loop keeps a parent in control of what their kid sees, with no open-ended chat surface anywhere in the experience.
01
Ship
A toy ships to a family and a story-activation link goes to the parent, not the child.
02
Approve
The parent reviews and approves a personalized story adventure built around the physical toy.
03
Read
The child experiences the approved story: no open-ended chat, no unsupervised AI conversation.
04
Continue
The relationship extends into a recurring, parent-approved story subscription.
Process
Built with the same operating discipline as my BA work.
Design consent as a first-class feature
Review queues, memory controls, and consent settings needed to be as real as the story engine itself, not an afterthought bolted on later.
Prove the loop on both surfaces
Build a Cloudflare-backed web demo and an Expo mobile parent-app prototype so the parent experience could be tested on the surface a real merchant would ship.
Current Build
- Research-complete PRD with regulatory and unit-economics analysis.
- Cloudflare Workers + Hono + React web app: landing, activation, portal, review queue, reader, gallery.
- Memory controls, consent settings, and a merchant dashboard.
- Expo mobile parent-app prototype mirroring the web experience.
Next Bets
- Real Expo Go / simulator QA pass on the mobile app.
- Wire Hyperdrive/Neon/R2/Queues/Workflows for production data.
- Harden the merchant dashboard for a real brand pilot.
- Pilot with a first toy brand.
What I learned
The safest version of an AI product is sometimes the better one.
It would have been faster to ship a child-facing chat toy. It would also have been the wrong call, for families, for the brand's trust, and for the regulatory reality of AI products that touch minors.
Constraining the AI to a parent-mediated, review-first role turned out to be a stronger product decision, not just a safer one: parents are the actual buyer and the actual trust relationship.
Research-complete, prototype in hand.
ToyTrail has a research-complete PRD, a working Cloudflare-backed web demo, and an Expo mobile parent-app prototype. Next: a first merchant pilot once the review queue, consent settings, and infrastructure wiring are production-ready.