The problem started in a classroom

Every week I volunteer in my daughter's 3rd-grade classroom to help three kids practice their multiplication tables. Thirty minutes. Three kids. One table of flashcards.

Thirty minutes sounds like a lot until you realize it goes by in a flash — attendance, getting settled, the inevitable pencil debate — and then you're left with maybe 20 usable minutes. That's just not enough repetition to make multiplication facts stick. Research on early math fluency consistently shows that spaced, frequent practice is what moves facts from effortful recall to automatic memory. One session a week doesn't get you there.

The obvious fix was to give kids a way to practice at home. But I didn't want to hand parents a worksheet. I wanted something kids would actually want to open.

The constraints that shaped the design

The "no cost" constraint was the most important one. Schools and families shouldn't have to pay for a practice tool, and neither should I have to absorb ongoing API or hosting fees just to keep a side project alive. That meant: no LLM calls per answer, no paid third-party services, no backend server to maintain.

Everything had to run entirely in the browser. As it turns out, that constraint led to some of the most interesting technical choices in the project.

What I built

The voice input turned out to be the best decision

I originally planned a simple number input field. Then I watched my daughter use an early prototype: she typed slowly, second-guessed herself, backspaced — the friction of typing was getting in the way of the math. Eight-year-olds are not fast typists, and for a timed practice drill, that matters.

Switching to voice input via the browser's Web Speech API changed the experience completely. She would tap the microphone button, say "forty-two", and move on. The latency was low enough that it felt instant. More importantly, saying the answer out loud adds another memory channel — auditory and verbal encoding on top of visual — which is genuinely better for memorization.

The main engineering challenge was making speech recognition robust enough for children's voices. Kids say "seven" and the transcriber hears "heaven." They say "forty" and it hears "14." I spent a good amount of time tuning the fuzzy matching: normalizing spoken numbers ("forty two" → 42), handling partial matches, and failing gracefully when the microphone picks up background noise.

Why animated characters and not just a scoreboard?

A flat quiz — question, input, next — gets boring fast. I've seen kids abandon perfectly functional learning apps because they feel like school. I wanted the characters to carry enough personality that kids felt like they were playing with someone, not just answering a machine.

Each character is a hand-crafted inline SVG with CSS keyframe animations: a gentle idle float, a celebration jump on correct answers, a side-to-side shake on wrong ones, a nodding animation while the character "talks." None of this required any image files — the entire game is a single HTML file. That means it loads fast even on a slow connection, and there are no broken image paths to debug.

My daughter's verdict: she picked Pip (the purple one) on her first session and has not switched since. Attachment to a character turns out to be a surprisingly strong motivator for coming back.

The build: one HTML file, no framework, no build step

The entire game lives in a single index.html. No React, no build pipeline, no node_modules folder. Inline CSS for styles, inline JavaScript for game logic and speech recognition, inline SVGs for characters.

This was a deliberate choice. A framework would have added complexity and a dependency chain that needs maintenance. For a self-contained interactive tool that needs to keep working years from now with zero maintenance, a single static file is the right architecture. The Web Speech API is a browser standard; there is nothing to upgrade.

The whole thing is deployed as a subfolder of my portfolio's GitHub Pages repository. No separate hosting account, no CI/CD pipeline. A git push is all it takes to update it.

Did it actually work?

My daughter went from uncertain on her 7s and 8s to answering them instantly within about two weeks of using the tutor at home in short daily sessions (her choice, not mine — that's the real metric). She now regularly beats her own score and will correct me if I quote a wrong multiplication fact in casual conversation.

What I would do differently

The speech recognition API is not available in all browsers (it works well in Chrome and Edge; Firefox support is partial). For a production tool I would add a numeric keypad fallback that appears automatically when the microphone is unavailable, so no child is blocked by a browser limitation.

I'd also love to add a parent/teacher dashboard that shows which facts a child is consistently missing — turning the practice into a targeted drill rather than a random quiz. That would require a small backend and user accounts, which brings back the cost and complexity I was trying to avoid. It's the right trade-off for a free, zero-friction tool, but there is clear product value sitting on the table.