Six Months of Watching My Own Kids Use AI: What I Had to Rebuild
A founder's log from six months of watching his 9- and 13-year-old use Xyplor daily — what surprised him, what broke, and what he redesigned.
What this is: a founder's log, not a case study. I have two kids, ages 9 and 13, who have been the alpha testers for Xyplor since before it had a name. This post is what six months of watching them actually use the product — not what I hoped they'd do with it — taught me. Some of it confirmed what we'd designed for. A good chunk of it sent me back to rebuild things I was sure were right.
The setup
I'm an engineer. I built the first version of Xyplor because I wanted my kids to be able to direct AI the way I get to at work — describing what I want, getting something real back, iterating — without handing them an adult chatbot and hoping for the best. My 9-year-old and 13-year-old have been using it most days for six months, on our family's own Pro plan (the same $34.99/month tier we sell, up to three kid profiles), with full parent-dashboard visibility into every prompt and every build.
I watched the logs. I sat next to them while they built. And I was wrong about more than I expected.
What surprised me
My 9-year-old didn't want a feature. They wanted a world.
I assumed younger kids would ask for small, concrete things — "make a button," "change the color." Instead my 9-year-old's very first sessions were requests like "a game where I'm a fox who delivers mail to other animals in a snowstorm" [VERIFY: exact wording]. Not a mechanic. A whole scene, characters and mood included.
That told me something the reflection loop we'd built (see our post on the four design principles) wasn't accounting for: the transferable skill for a 6-to-9-year-old isn't "here's the code concept you just used." It's "here's how you turned a vague feeling into a specific thing." We were teaching the wrong layer of the skill to that age band.
My 13-year-old cared more about the gallery than the build
I expected the 13-year-old to spend most of their time iterating — "make the boss harder," "add a second level." Some of that happened. But the dominant behavior, once they discovered the parent-approved publish flow, was building toward an audience. They'd ask "will this look good in the gallery" before asking "does this work" [VERIFY: exact wording]. Building was instrumental to publishing, not the other way around.
That's not a bad instinct — wanting an audience for your work is a real motivator, and we didn't design against it. But it meant our reflection prompts, which were written assuming the kid's next question was "what should I improve," were often just in the way. The kid already knew what they wanted to improve. They wanted to know if it was good enough to show someone.
The AI conversation logs were more interesting than the finished games
This was the biggest surprise, and it's the one that changed how I think about the whole product. I'd check in on my kids' creations — is the game fun, does the quiz make sense — and largely ignore the conversation trail that got them there. Then I started reading the parent-dashboard logs end to end, and that's where the real signal was: which prompts got vague answers, where a kid gave up and simplified their ask, where they pushed back on the AI's first attempt instead of accepting it.
The finished product told me what my kid built. The conversation told me how they were learning to direct AI. I'd been building the dashboard around the wrong artifact.
What I had to redo
Shorter reflections, sooner
The original reflection screen ran three or four sentences after every creation — what the AI did, the skill practiced, a couple of next steps. Watching my 13-year-old tap through it without reading, and my 9-year-old lose the plot halfway through, I cut it down hard. What's live now is closer to one line plus a single next-step suggestion. Everything past that, we moved to be optional and tappable rather than shown by default. The instinct to teach more per screen was mine, not theirs.
Building the "Spark" on-ramp for younger kids
The fox-in-a-snowstorm moment above is part of why we built a dedicated on-ramp for the 6–8 age band — what we call Spark: a concept-before-tool step, with voice input and a picture-based prompt picker for kids who aren't fluent readers yet, before they ever touch the open-ended prompt box. It exists specifically because my 9-year-old (and kids younger than them, who we later tested with) do better starting from "pick a world" than from a blank text field. That page lives at xyplor.com/ages-6-8 now. It didn't exist in the first version I built for my own kids.
Rebalancing what the AI does at each step
Once I started reading conversation logs closely, I noticed where kids got impatient waiting on something that didn't need to be slow. Interactive builds — games, quizzes, tools — run on Claude Opus for the first pass because that's where the build needs to hold up structurally. Non-interactive builds — stories, websites, podcasts — run on Sonnet. But the small back-and-forth moments, the "give me a hint" or "what does this mean," were originally running through the same heavier path as the builds themselves, and kids noticed the lag. We moved those auxiliary steps to Claude Haiku specifically because a 9-year-old's patience for a hint is measured in seconds, not the 60 seconds we budget for an actual build.
Screen time that rewards finishing, not opening
I wrote about this as a principle before it was fully true in practice. Early on, our bonus-time logic was generous about what counted as "active" — enough that a kid could leave a project half-finished, poke at it occasionally, and still accrue meaningful bonus minutes. My 13-year-old found that gap in about a week, entirely by accident, just by working the way distracted teenagers work. We tightened it so bonus time is tied to actually completing something — a project, a journey step, a saved creation — not to time-in-app. The base limit and the earnable cap are still both parent-set and independent, but "active" now means something closer to what I meant when I designed it.
What didn't need to change
Not everything got rebuilt. The full parent-visibility dashboard, the PIN gate, the publish-approval step before anything goes public — none of that changed, because none of it surprised me. My kids didn't try to get around it, complain about it, or even seem to register it as friction. It was just the shape of the room they were creating in. That's probably the best outcome a safety layer can have: invisible until you go looking for it.
The no-messaging design held up too. My 13-year-old occasionally asked why they couldn't chat with a friend's profile directly in the gallery, and the honest answer — that's by design, not a missing feature — was enough. Co-create, where a kid can invite a known friend to build on a shared project with both sets of prompts visible to both parents, covered the one real use case that came up: working with a friend, not chatting with strangers.
What I'd tell another parent watching this happen
If you're evaluating any AI product for a kid — ours or someone else's — the thing I'd tell you to actually watch is not the output. Watch the conversation. A polished game or a clean website tells you the AI did its job. The prompt history tells you whether your kid is getting better at asking for what they want, noticing when the first answer isn't good enough, and pushing back with something specific instead of just re-rolling. That's the skill that transfers. It's also the one that's easiest to build a beautiful dashboard around and never actually read.
Six months in, my kids are still my two toughest product reviewers, and they still find the gaps faster than any test plan I write. That was true on day one and I expect it'll be true a year from now. It's the reason the "parent watching closely" part of this isn't a feature we shipped once — it's the process the whole product runs on.