Product direction / Case note
Drift Tones: Making a Small Browser Tool Feel Complete
How I turned a working Web Audio experiment into a calm, accessible product—using tight scope, honest language, and iterative direction with AI coding collaborators.
Start with the job, not the technology
Drift Tones began with a narrow question: could a browser produce a useful stereo tone experience without an account, an app installation, or a service running behind it?
The first technical spike answered that quickly. Two tones could play at the same time, one in each stereo channel, and the browser could change them in real time. The more important work came afterward. A functioning audio graph is not yet a product. I needed to decide who the tool was for, what it should help them do, what controls they actually needed, and what claims it should refuse to make.
I framed the job around ordinary moments: taking a short break between tasks, reading without music, creating a background for focused work, or winding down at the end of the day. That framing kept the product out of two unhelpful categories. It was not a technical synthesizer for people who wanted dozens of waveforms and modulation controls, and it was not a clinical-looking “brain optimization” product making promises the evidence could not support.
That led to aggressive simplification. I kept four presets based on familiar Delta, Theta, Alpha, and Beta spacing labels, but paired them with plain-language modes such as Slow drift, Unwind, Settle, and Focus. I removed waveform choice and standardized on sine waves. I put one Start/Pause control and volume in the main path, while moving base frequency into an advanced disclosure. The guiding test was whether a visitor could understand the useful interaction in about five seconds.
A browser-native audio engine
The core engine uses the Web Audio API rather than prerecorded tone files. It creates two sine oscillators and routes them through a two-channel merger: the left channel plays the selected base frequency, and the right channel plays that base plus the preset spacing. At the default 200 Hz base, the Alpha-inspired 10 Hz preset produces 200 Hz on the left and 210 Hz on the right. The interface exposes those numbers so the preset is transparent rather than mystical.
This architecture is deliberately small. The tone is generated on the device; the application does not need microphone access, an account, or server-side audio processing. The core can be delivered as static HTML, CSS, and JavaScript. That reduces operational complexity and makes the privacy story easier to explain: press a button and the browser creates the sound locally.
Small audio tools still have edge cases. Browsers require a user gesture before starting audio, so Drift Tones does not attempt autoplay. Starting at full gain can produce an unpleasant click, so the master gain begins near silence and rises smoothly toward the selected volume. Pausing reverses that process before the oscillators stop and the audio context closes. The interface says “Fading out” during that transition instead of pretending the action is instantaneous.
Mode switching is also continuous. If someone changes from a 10 Hz spacing to a 6 Hz spacing while audio is playing, the existing oscillator frequencies move toward their new targets with Web Audio scheduling. The page does not tear down and recreate the entire player. Volume and base-frequency changes use the same smoothing approach. Those details are invisible when they work, but they are the difference between a demo and a tool that feels considered.
Product correction was part of the build
The evolution of Drift Tones was not a straight line. An early designed version worked technically, but I judged it worse than the raw spike. It split attention between introductory artwork and a separate control column, making the product look polished before making it obvious. I rejected that direction and treated the next pass as a product correction rather than a cosmetic revision.
In the second version, the player became the center of the first screen. Current mode, actual left/right frequencies, four tactile preset buttons, Start/Pause, and volume lived together in one calm card. Marketing copy moved down. Technical controls became secondary. The working name briefly changed to Quiet Current so the redesign could be evaluated as a distinct artifact rather than a coat of paint on the earlier version.
That iteration is representative of how I work with AI assistance. I set the brief, constraints, acceptance criteria, and product priorities; AI coding collaborators helped implement and revise the static artifacts. I reviewed the result against the actual user job, rejected a direction that met the feature list but missed the experience, and tightened the next brief around tool-first design. I do not think useful AI-assisted development means accepting the first plausible output. It means making judgment legible enough that collaborators—human or machine—can act on it, then verifying the result.
The later Drift Tones version expanded carefully. It restored the Drift Tones name, added optional ambience loops such as forest rain, stream, ocean, rain, and wind, and kept them independent from the generated tones so people could use either layer or combine them. It also grew from a single experiment page into a small public site with practical guides, safe-listening notes, privacy and terms pages, theme switching, and search-oriented metadata. The center of gravity remained the same: the player comes first.
Calm includes accessibility and restraint
The visual system uses a low-glare dark palette, restrained motion, large controls, and responsive layouts. On narrower screens, four mode choices collapse from four columns to two, and primary controls stack rather than compress. The navigation wraps instead of becoming an invisible interaction. A light theme is available and respects a saved preference.
Accessibility is part of the interaction model, not an afterthought. Buttons carry real labels and keyboard behavior. Selected mode and ambience controls update aria-pressed. Playback status and frequency changes sit in an aria-live region. Inputs have associated labels, focus states remain visible, and the animated player orb stops moving when the user requests reduced motion. The volume defaults to 18 percent and is capped in the interface, with repeated reminders to start low and stop if the sound feels uncomfortable.
I also treated copy as a safety feature. Delta, Theta, Alpha, and Beta describe the spacing presets; they do not guarantee an effect. The site talks about work breaks, reading, focus rituals, and winding down, but does not claim to treat anxiety, insomnia, ADHD, or any medical condition. Headphones are recommended because they make the stereo split clearer, not because they unlock a health benefit. A dedicated listening guide reinforces low volume, short initial sessions, and the option to use speakers or stop entirely.
What the project demonstrates
Drift Tones is modest by design, but it exercises a useful range of product skills. I translated a personal idea into a bounded job-to-be-done, chose a browser-native architecture, directed AI-assisted implementation, and used critique to correct a technically valid but strategically weak design. I balanced advanced capability with a simple default path, made changing audio state feel smooth, and built accessibility and non-medical language into the product rather than adding them at the end.
It also shows why I like small tools. A focused product exposes judgment clearly. There is nowhere to hide a confusing control behind an onboarding flow or a weak value proposition behind a feature roadmap. Drift Tones has to earn its place with one interaction: choose a mode, press start, and make the room feel a little more intentional. Everything else supports that moment.