A few years ago, weekends for my friend and me meant what they mean for most people before kids: parties, clubs, late nights, loud music.
Then we both became parents. And the weekends transformed the way they do for every new parent — the clubbing quietly turned into in-house get-togethers. Two families, one living room, toys everywhere, kids running the show.
And at every single get-together, the same scene played out. Our kids — barely past their first birthdays — would crawl straight past the toys we'd bought them and reach for our phones. Every time. Whatever glowed, won.
We had the same conversation every weekend: screens are going to be part of their lives whether we like it or not — so why is everything on them either mindless or manipulative? Most parents end that thought with "someone should build something better." One weekend we realised: he's an engineer, I've spent twelve years across QA and product. We were "someone."
There was a professional itch too. At Deutsche Telekom I own platforms that 10M+ users touch daily — but every decision there travels with an org: designers, legal, release trains, someone to catch what I miss. I'd never once owned a product completely, every call from problem statement to store listing. This was the chance to do both: build for our own kids, and build 0→1 with no safety net.
The result is Kids Kala — a free learning app for kids aged 2+: tracing letters and numbers, shapes, colors, and games. It's live on both stores. He led the engineering. I owned the product: problem definition, PRD, prioritization, QA, release.
This isn't a launch announcement. It's what going 0→1 with no safety net taught me that a decade at scale didn't — and how AI tools let two people ship like six.
From living-room playdates to a live app on both stores.
Our User Research Happened on the Living-Room Floor
Before writing a word of the PRD, we had something most products never get: months of accidentally watching our target users up close, every weekend. What held their attention and for how long. What frustrated them into tears. Which apps they abandoned in ninety seconds. Our kids became user zero and user one — and they are ruthless testers. Kids don't write polite feedback. They just leave.
When I then dug into the kids' app market properly, the problem wasn't a lack of apps. It was that almost all of them failed the same four ways:
Before we wrote a single line of code, I wrote a one-sentence problem statement. Every feature debate for the next several months ended with the same question: which of these four gaps does it close? If the answer was "none," it didn't get built.
A persona isn't a slide. If it doesn't change what you build, it's decoration.
The Decision That Shaped Everything: One App, Three Worlds
Our parent persona — a mom with a 3-year-old and a 7-year-old — had one complaint that stuck with me: "Every app is too easy for one kid and too hard for the other."
That single pain point became our biggest architectural bet. Kids Kala doesn't have difficulty settings buried in a menu. The entire app transforms based on the child's age:
Early Birds (2–4)
Sky & clouds world with a friendly bear. Big targets, simple tap games, gentle pace.
Preschoolers (3–5)
Underwater world with Splashy the octopus. Tracing, emotions, counting.
Star Learners (7–9)
Deep-space world with Cosmo the astronaut. Quizzes, word skills, real challenge.
Same app, separate child profiles — each kid gets a world that fits their stage. The 7-year-old never sees "baby stuff." The 3-year-old never hits a wall.
0→1 Is a Different Sport
At scale, my job is often protecting a product from bad changes. At 0→1, there's nothing to protect yet — every hour spent on the wrong thing is an hour stolen from the right one. Two things saved us:
📋 Tagging every single requirement P0 / P1 / P2
The stroke-scoring engine was P0 — "tracing apps with no feedback quality" was a gap we existed to close, so launching without it made no sense. The parent dashboard everyone assumes a kids' app needs? P2. It hurt to defer things I loved. That's exactly the job.
🚫 Writing down what we would NOT build
No social feeds. No leaderboards. No embedded video. No subscription gate at launch. Nothing for ages 10+. Honestly? Our non-goals list ended more debates than the priority list did. When you're two people, everything you say no to is time you get back.
Quality isn't a QA phase at the end. It's a product decision you make at the start.
My QA years earned their keep here. Android renders shadows black on transparent cards. Safe areas leak white patches behind themed backgrounds. A 3-year-old's finger doesn't tap where an adult's does. A decade of hunting edge cases turned out to be most of what early product work actually is — imagining every way the experience breaks for a real person before they find it.
The AI Toolchain (the Part Everyone Asks About)
Let me be direct: two people could not have shipped this app three years ago. Not with day jobs. Here's what changed:
Claude & Claude Code
Product sparring partner and senior engineer in one. Pressure-tested the PRD, argued against my own prioritization, built the curriculum engine, debugged the weird platform issues.
Cursor & Copilot
Made the daily coding loop fast. Shaving minutes off hundreds of small tasks is what makes nights-and-weekends shipping actually possible.
AI design tools
Mascots, themed backgrounds, icons, coloring-page art. Three complete visual themes with zero illustrator budget.
But here's the takeaway I'd want you to remember if you remember nothing else:
AI collapsed the cost of execution — not the need for judgment. Every tool would happily build the wrong thing faster.
Deciding what to build, for whom, in what order, to what quality bar — none of that got automated. If anything, when execution gets cheap, product thinking becomes the bottleneck. And the differentiator. I'd tested AI-generated output for a living and built LLM evaluation frameworks at work; building with these tools full-stack was the other half of that education.
What I'd Tell Anyone Who Wants to Build
Ship something real, however small. A side project with actual strangers using it rewires how you think about every framework you've ever read. Real prioritization tradeoffs with real stakes — there's no substitute.
Your existing skills transfer more than you think. Edge-case thinking, user advocacy, knowing "works" from "works well" — QA people spend careers building the exact muscles product work demands. Whatever your role is, there's a version of this true for you too.
Write the PRD nobody asked for. Half my "obvious" requirements fell apart when I had to define them precisely enough for someone else to build. Writing is where fuzzy thinking goes to get caught.
Use AI to cover more of the stack. The tools now let one person credibly span product, QA, and a real slice of engineering. The people who figure out that leverage first will define what the PM role becomes.
Want to Help? I Have the World's Toughest Beta Testers Waiting
Kids Kala is live, free, and honest-to-goodness fun to watch a kid use. It survived the toughest QA panel we know — our own kids at those weekend get-togethers. If you've got a little one aged 2+ at home, their brutal, unfiltered feedback is exactly what we want next.
Letters, numbers, shapes & colors through play, for kids 2+
▶ Google Play 🍎 App StoreAnd if you're building a product where this kind of end-to-end ownership matters — from problem statement to store listing — let's talk. I'm exploring product roles where hands-on building is valued, not just tolerated.
What's the one thing you'd build if execution were free? I'd love to hear it.
Loading comments…