What broke my first Web Audio prototype (and the one rule that fixed the game)

I’ve been building a tiny browser game—working name Dialed Sound Game—where you hear a few short tones and try to match each frequency from memory. Nothing fancy on paper: a slider, a score, a daily run if you want it.

The part that almost killed the project wasn’t DSP theory. It was UX dressed up as “fairness.”

In the first prototype you could drag the slider while the tone was still playing. People scored higher. They also stopped trusting the result—because it wasn’t memory anymore, it was micro-adjustment with your eyes open. I shipped a harsher rule instead: once you’re guessing, the tone is done. Complaints went up for a day; retention felt honest after that.

On the audio side, the web is cooperative until it isn’t. Autoplay policies, Bluetooth routing, and laptop speakers that lie about highs all show up as “your game is broken.” I kept listen levels conservative and avoided turning the exercise into a piercing test tone. It’s a casual loop; I still put a plain disclaimer on the page that it’s not clinical testing—because someone will assume otherwise.

Stack-wise it’s a Next.js shell with the interactive bits in client components—nothing exotic, just the usual discipline of scheduling work off a gesture you still own.

If you try it, use headphones. Not because I’m precious about it—because cheap hardware makes people blame the software first.

That’s it: https://dialedsoundgame.com/

If you’ve shipped Web Audio games and you disagree with the “no scrubbing during playback” rule, tell me what you did—I’m genuinely curious.