My daughter’s media player has several tabs now — a general folder of nursery rhymes, hymns, classical pieces and kids’ pop songs; a folder of folk songs I made pictures for myself; a Bible-verse song folder; and a couple of separately purchased audiobook and story collections. On her own device, she picks what she wants by tapping a cover picture, the same as always. That device is Wi-Fi only, though, and it stays home — it isn’t a phone with its own data plan, so it never comes along in the car. The problem was everywhere outside our own Wi-Fi.

Anywhere outside the house — most often in the car — her device simply isn’t with her, so a parent’s own phone stands in for it. She still asks for a song by name, the same way she always has, and whoever is driving ends up holding their phone, unlocking it, opening the right tab, and scrolling through covers to find the one she wants. That’s the part that actually worried me. Not screen time, not the songs themselves — a driver looking at a screen and searching for something, at speed.

I logged the request the way I log every prompt I type, and it’s worth quoting in full because it says exactly what the problem was, not what the feature should be:

💬 Prompt that worked “When my daughter has her own phone, she picks and plays songs herself. But outside the house — like while driving — her phone isn’t set up for that, so my wife or I end up searching for the song she wants on our own phone, which creates a bit of danger while driving. Could we make it so she just says the tab name and the song title out loud and it plays?”

The Proof: One Evening, One Prompt, Working the Same Night

I sent that prompt at 19:12. By 20:26 the same evening, I’d tested it and logged the result: “Implemented well. Works well.” No back-and-forth in between — the first pass worked.

What we actually use now: a small microphone button floats above the tab bar, always in the same reachable spot. Tap it once, say one sentence — tab name, then song title — and let go. A half-second later the app either starts playing the song and says its title out loud, or admits out loud that it couldn’t find a match. No unlocking a phone and reading a grid of covers while driving. Just talk, listen, drive.

The Story: Naming the Danger Got a Better Feature Than Naming the Wish

I could have asked for this months ago as a convenience — “wouldn’t it be nice if she could just ask for a song.” I didn’t, because it didn’t feel urgent enough to interrupt other work for. What changed my mind was noticing the actual risk: a driver’s eyes and one hand going to a phone screen, repeatedly, because a three-year-old wants a different song than the one currently playing.

Framing it as a safety problem instead of a nice-to-have also shaped what got built. The result isn’t a general voice assistant that understands anything you say to it — it’s narrow on purpose. It only searches song and story titles across her tabs, and it says something back out loud either way, so a driver never has to glance at the screen to know whether it worked. A broader “ask it anything” version would have been more impressive and less useful for the one situation I actually needed it for.

The How: Nothing But the Browser, and a Judgment Call About Scope

The recognition itself runs entirely on the browser’s own speech API — SpeechRecognition (webkitSpeechRecognition on the Android Chrome we actually use). No external speech-to-text service, no API key, no per-request cost. It’s built into the browser, the same way speechSynthesis — also free, also on-device — reads the result back out loud. Both come with one real limitation worth knowing before you plan around them: this pair is reliably available on Android Chrome, and the app checks for it and quietly hides the microphone button on browsers that don’t support it, rather than showing a button that fails.

The rest of the feature is plain text handling, run entirely on the phone after the browser hands back a transcript — no extra network round-trip to match a song:

  1. Tap once, get one sentence back. The recognizer is set to single-shot, not continuous listening — it captures one utterance and stops, which matches how she actually talks to it ("[folder name] [song title]") and avoids the battery and privacy cost of an always-listening microphone.
  2. Strip the filler words first. Real requests come out as “…play it for me” or “…I want to hear it,” not a clean title. A list of common Korean sentence endings (“play it,” “I want to hear it,” “please,” and so on) gets trimmed off the end of the transcript before anything else happens.
  3. Match a folder name at the start of the sentence, if there is one, to narrow the search to just that folder. If she names a folder that doesn’t match anything, or names no folder at all, the search just falls back to everything.
  4. Score the remaining text against every title already loaded in memory. An exact match scores highest, a title that starts with what she said scores next, a partial match scores lower still, and a last-resort character-overlap ratio catches close-but-imperfect matches — a minimum score is required before the app accepts a guess instead of admitting defeat.
  5. Say the result out loud either way. “Playing [title]” if it found one, “couldn’t find that song” if it didn’t — so a driver gets a clear answer without looking over.

The one deliberate scope decision worth naming: not every tab is searchable this way. A handful of other tabs in the same app — one built around saved video links, one for a subject where entries are numbered rather than named, a growth-photo archive, a language-learning tab, and an e-book tab — were left out on purpose, because their titles either aren’t song names at all or overlap too easily with something else. Saying no to those kept the feature reliable for the tabs where it actually works well, which mattered more than covering everything.

Total added cost: $0. The only two ingredients — speech recognition and speech synthesis — are both already sitting inside the browser everyone in this house already has.