It’s the June school holidays. I have three children. All three need to revise. None of them want to.
If you’ve managed one child’s revision schedule, you know it’s a small war of attrition. Manage three, and you’re fighting on three fronts with three different attention spans, three different weak spots, and exactly one of you.
I didn’t start this project trying to build software. I started it trying to survive the holidays.
It started as a checklist
My first move was simple. I used Claude — Anthropic’s AI assistant — to help me build revision checklists for each of my kids. Nothing fancy. Just a way to keep track of what each child needed to practise, so I wasn’t holding it all in my head.
It worked. But a checklist is still a checklist. Nobody gets excited about ticking boxes, least of all a nine-year-old on holiday.
What my kids actually needed wasn’t more structure. It was something they’d want to do. So I asked myself a different question: could I build something that made times-tables practice feel less like homework and more like a game?
I’m not a developer. I had no plan to learn to code over the school holidays. But I had Claude Code — Anthropic’s AI coding assistant — and I figured I’d see how far “describing what I want” could actually get me.
It got me a lot further than I expected.
From checklist to game, without me asking for it
I described what I wanted in plain language: something for multiplication, something that felt fun, something my kids would come back to.
I didn’t ask for gamification. Claude designed it anyway — a points system, levels, the works. That surprised me. I’d treated the AI as a typist for my instructions. It turned out to be more like a junior developer who’d actually thought about the brief.
That set the tone for everything that followed. I’d describe the problem, not the solution, and let Claude propose how to solve it.
The moment that told me this was different
Here’s the bit I keep coming back to.
I asked Claude to build a login system — username and password, the standard setup. Reasonable request, I thought.
Claude pushed back. It pointed out that the people using this app would be children, and a password is exactly the kind of thing a child forgets, mistypes, or writes on a sticky note where everyone can see it. It proposed a 4-digit PIN instead — something a seven-year-old could actually remember and type without help.
That’s not a feature. That’s context awareness. I hadn’t told Claude the users would be kids in that specific message — but it had picked it up from everything else we’d discussed and used it to question my own instruction. It made a better call than I did, for an audience I knew far better than it did.
I went with the PIN. Obviously.
Turning it into something I could actually trust
Once I realised this could become more than a one-off toy for my own kids, I got nervous about the usual thing: would it break? Would changes I asked for quietly wreck something that used to work?
So I imposed a proper process on the whole thing — the kind of discipline you’d expect from a real software team, not a dad coding by Wi-Fi during the school holidays:
- I describe a feature. Plain language. “Add a leaderboard.” “I want this to support more than just multiplication.”
- Claude plans before touching any code. I get to read the plan, push back, or extend it before a single line is written. More than once, I changed direction at this stage — at zero cost, because nothing existed yet.
- Once I approve, the work starts on its own branch, separate from the live app.
- Tests get written first — and they’re meant to fail. The test has to prove the feature doesn’t exist yet before anyone builds it.
- Then the feature gets built, and the tests run again. Everything has to pass.
- Only then does it merge into the main version and go live.
I’m not a developer, but I know enough to know that’s not how most casual side projects get built. It’s closer to how it’s supposed to work at a proper software company — and the AI followed the discipline without complaint, every single time.
It paid off. The test suite caught a real regression during the leaderboard build — a bug that would have shipped if I’d skipped the process and just pushed straight to the live app.
What actually got built
In two days, working in short sessions, this is what shipped:
- A drill engine — 15 questions per round, weighted towards the facts a child is weakest on
- Combo multipliers — streak bonuses for consecutive correct answers
- An XP levelling system with six ranks, from Beginner up to Legend
- Mastery tracking, showing exactly which times tables are nailed and which need more reps
- A leaderboard, so kids could see how they stacked up against each other
- Persistent accounts with PIN login, so progress is saved between sessions
- A module hub, built so I can add Division and Chinese spelling dictation later without rebuilding everything
All of that sits in one HTML file and one PHP file. No frameworks, no complicated build process — by design, so deploying an update is one command, not an afternoon.
Across those two days: 10 commits, 92 automated tests, and most individual features going from idea to live in well under an hour.
What happened when I shared it
I shared the app in a few parent group chats. Nothing more ambitious than that.
So far: 36 signups, 309 sessions played, and just over 138,000 points earned collectively. Three children — two of them mine — have already hit Legend status, the top rank. Which tells me I’ve probably calibrated the difficulty a touch too generously. That’s a fix for another day.
What I didn’t expect: adults are playing it too. A few parents admitted they’d opened it “just to test it” and ended up doing a few rounds of multiplication themselves. My own two children are now in open competition for the top two leaderboard spots, which has done more for their times-tables fluency than any worksheet I’ve ever printed.
The actual point
I want to be clear about what this story is and isn’t.
It isn’t “look how clever I am with technology.” I can’t write the code in that app. I couldn’t tell you what half of it means.
What I can do is describe a problem clearly, make decisions when given options, insist on a process that catches mistakes, and recognise a good idea — like a PIN instead of a password — when the AI hands me one.
That, it turns out, is enough to ship something 36 families are actually using. Not a prototype. Not a proof of concept. A live tool that solved a real problem I had, then turned out to solve the same problem for other parents too.
The barrier to building real software has dropped further than most non-technical parents realise. You don’t need to learn to code. You need a problem worth solving, the patience to describe it properly, and the discipline to insist on getting it right before it goes live.
I’m already planning Division next. Possibly Chinese dictation after that. If you want to see what came out of one chaotic June holiday, my kids and I would genuinely like your feedback — including, perhaps, why your child is now beating mine on the leaderboard.
Try it here: johnnykoh.sg/homework/index.html