I paid for the best-rated Mac dictation app — two days later I started writing my own
I was a paying customer. The app had stellar reviews. I assumed I was the problem.
Then I realized I wasn't. And spent six months building the tool I'd actually wanted.
A confession to start: I've been a programmer for 24 years. When I have a problem with a tool, my first instinct is "the tool is fine, I just don't know how to use it". I will read three forum threads, watch a YouTube tutorial, and try four configurations before I will admit the tool is bad.
So when I bought what was, at the time, the highest-rated dictation app on the Mac App Store and felt frustrated by it, my reaction was: I must be using it wrong.
Two days later, after concluding I was not in fact using it wrong, I opened a new project in my editor.
How I got here
For the last year, my development workflow has changed shape. I don't write much code by hand anymore. Most of what I do is talking to AI agents — describing what I want, reviewing their proposals, asking for revisions, occasionally jumping in to clarify a constraint.
The tooling around this is improving fast. Claude Code, Cursor, aider, codex — they're all impressively capable.
The bottleneck isn't them. It's me.
Specifically, my hands and my keyboard. When you stop being the person who writes code and start being the person who directs code, you produce a lot more text per day than you used to. Long, descriptive prompts. Multi-paragraph requirement breakdowns. Spec files. Followups. Clarifications. The volume of typing scales with the number of agents you're managing.
After about two months of this, my wrists started to hurt. Not catastrophically — not enough to stop work — but enough to know that the trajectory was bad. I'd hit 10x the typing volume of any previous job. My setup wasn't going to survive that.
So: voice. Obviously voice.
That's when I went shopping.
What I bought
I bought the most-recommended dictation app for Mac. I won't name it — they're a real company, they have a real product, and naming them in a "and here's why I built a competitor" piece feels uncool. The point isn't that they're bad. The point is they're built for a different problem.
I installed it. Set up my hotkey. Started dictating.
It worked. Until it didn't.
The first thing I noticed: when I pressed the hotkey to start talking, there was a delay. Maybe 300 milliseconds. Then the audio capture would start. If I pressed the key and immediately said "hey claude, can you" — the "hey" was gone. Sometimes "claude" too.
The fix the app suggested was to wait a beat after pressing the key before speaking. Train myself to add a pause.
OK fine. I'm a programmer. I can train myself.
I tried. For a week.
The problem with training a pause is that it works in deliberate mode and fails in flow mode. When I'm thinking carefully about a complex prompt, I'm fine — I press, I pause, I dictate. When I'm in a fast back-and-forth with an agent, energetic, mid-thought, I forget. Press and go. First word lost. I'd have to repeat. I'd lose the thread of what I was saying.
This is a minor friction. Mosquito-bite friction. By itself, not a deal-breaker.
The second thing I noticed was bigger.
The hands-free lie
The app had a "hands-free" mode. Toggle it on, talk continuously, see your text stream into the active app. Sounds great. Pacing the kitchen with bluetooth headphones, dictating to my laptop on the desk, sounds like the future.
In practice the "streaming" wasn't really streaming. I'd talk for thirty seconds straight, see nothing on screen, and only when I ended the session did the whole paragraph drop in. Talk for another minute, end session, second paragraph appears.
Imagine dictating into a void. You don't see what you said until you're done.
You can't read what you're writing while you're writing it. That sounds like a small thing. It's not. Without seeing the text grow as you speak, I couldn't catch myself misspeaking, course-correct mid-thought, or notice when the model misheard a technical term until well after the fact.
I went back to typing through carpal tunnel.
The third thing
The third thing was the killer.
I don't just dictate at a single text field. I have multiple destinations:
- A terminal window with my main agent (an SSH session into a Linux box where the orchestrator runs).
- An editor window for code I'm reviewing.
- Slack for chats with humans.
- Linear for issues.
- A web browser where I might be looking at agent outputs.
For each of these I want different post-processing. Raw text into the terminal. Cleaned-up text into Slack. Structured JSON into Linear's API. Polished prose into a tweet.
The dictation app I bought had one output target: wherever the cursor was. One pipe. No branching. No transformation. No way to say "this dictation goes to Linear, not to my cursor".
You could buy a second app to handle automation. But the dictation tool wasn't designed to talk to that automation tool. They lived in separate worlds.
That was the moment I realized the tool I was using wasn't bad — it was just built for a different person. It was built for someone writing emails and Notion docs. I'm someone wrangling 30 AI agents simultaneously.
There was no Mac dictation app built for the second kind of person. So I started writing one.
What I built
A confession: I had no plans to ship this. I was scratching my own itch. The first version was three files of Rust code that did exactly one thing: capture audio fast and inject text fast. Press hotkey, talk, see word.
That worked. Cold-start latency under 20 milliseconds. First word never lost. I used it for a week and felt — for the first time since starting the agent-driven workflow — that the input pipe wasn't a bottleneck.
Then I added a second hotkey. ⌘+1 would route the dictated text to my SSH session no matter what window was focused. I didn't have to alt-tab to the terminal. I'd be reading code in my editor, hold ⌘+1, talk to my orchestrator agent. It would receive the message in the terminal pane it was running in.
Then I added a third hotkey for posting to Linear. With a small local LLM in the middle that converted my casual dictation into a clean issue title + description.
Then chunk-on-pause streaming hands-free — text appears in chunks at the natural pauses in your speech, not held until the end of the session — because I missed pacing the kitchen and seeing what I'd just said.
Then voice fingerprinting, because my son walks into my office and starts talking, and I don't want his "dad, can I have a cookie" to end up in the middle of my system architecture proposal. (The app learns your voice over a few days; after that, only your voice triggers transcription.)
Each feature was its own week. Each was a thing the existing tools didn't do, that I wanted, that I knew exactly how to build because I had felt the absence.
Six months later, I have a Mac app that I use every day for hours, and that has not glitched on me even once. A full release of any sweat or panic or "ugh this thing again". It just works.
I started showing it to other developer friends. They wanted to use it.
So: I'm shipping it.
What it is now
It's called SpeechButton. It's a menu bar app that looks like this:
The default hotkey is "Right Command". Hold it, talk, see text appear at your cursor in 20 milliseconds.
It has:
- Push-to-talk and hands-free modes, both with chunk-on-pause streaming (text appears in chunks at the natural pauses in your speech, not held until the end of the session).
- Multi-hotkey routing: configure as many hotkeys as you want, each routing to a different destination — your cursor, an SSH session, a deployed HTTP endpoint, a Linear issue via API, anything you can describe in a config file.
- Local LLM transformer (optional): take your raw dictation, run it through a small on-device language model with a custom prompt, then send the result. Used for things like "convert my dictation into structured JSON for an API call".
- Voice fingerprinting: after a few days, the tool only responds to your voice. Useful for shared offices, kids, partners, podcast playing in the background.
- Plain-text config that AI agents can read and modify. You can ask Claude Code to set up a hotkey for you.
- 100% on-device audio. Your voice never leaves your Mac. (The optional transformer can be cloud-based if you want, but it's local by default.)
It's built in Rust for the latency-critical paths. The UI is SwiftUI. The whole thing is heavily optimized for Apple Silicon — in some workloads up to 40× faster than the same operations done with cross-platform tooling.
What it isn't
Some honest disclaimers:
- Mac only. Apple Silicon, macOS 14+. The Apple Neural Engine optimization is load-bearing. Cross-platform would mean a slower, worse tool — and I don't want to ship that.
- It's an opinionated tool for developers. The "default user" is someone who has at least heard of an SSH session. If you want a one-click voice-to-Notion app, this isn't it.
- Pro tier costs $7.99/month ($69.99/year, or $129.99 one-time — Lifetime, up to 3 Macs). The free tier gives you 5 minutes of transcription per day, no account required, which is plenty if you only use it occasionally. Hobbyists generally fit in the free tier; the pro tier exists for people who use it for hours a day.
Try it
It's at speechbutton.com.
Or with one terminal command:
$ brew install --cask speechbutton/tap/speechbutton
If you have voice-tool feedback or want to talk shop about agent-driven dev workflows, I'm @SpeechButton on X. I read everything.
I built this because the tool I wanted didn't exist. If you're someone who would have wanted the same tool — I'd really like for you to have it.
More in this series: the engineering behind the 20ms budget, and how I route one voice across thirty agents.
SpeechButton