My Agents Don't Care About My Spelling: Why I Built My Own Voice Dictation App

I have stopped typing. Not completely, but close. Most of what I hand to my agents now leaves my mouth, not my fingers: on the phone while I walk, at the desk while I pace, and once, memorably, from the saddle of my bicycle, where I described an app out loud and found it built, deployed and posted by the time I got home. That ride became an episode on my channel, and the quiet hero of it was a voice dictation app.

For the past couple of weeks that app has been one I wrote myself. It is called dictum. It runs on my Mac and my Android phone, it costs me roughly nothing per month, and it does less than the product it replaced. That last part is the point of this post.

dictum is private, bespoke software. It exists for exactly one user, me, and I have no plans to publish it, put it in an app store or open-source it. That is the whole idea. What I am sharing here is the why, the design and the roadmap, so you can take whatever is useful and build your own dictum, in whatever shape fits you.

I was a happy customer

Let me be clear about where I started, because this is not a “the incumbent is bad” story. I have been a loud fan of Wispr Flow. I used it every single day. In one month I spoke around 130,000 words into it at about 163 words a minute, which their own stats told me was roughly 120 words a minute faster than I type, and which put me somewhere in their top fraction of a percent of users. It changed how I work. Once talking becomes the way you hand out instructions, it stops mattering where you are sitting.

Then earlier this month Sarvam AI shipped Kivi, and I wrote about it on LinkedIn. It kept up with my long voice notes, the latency was on par, and my Hindi tests were smooth. I said publicly that two things stood between me and a switch: an Android app, because most of my dictation happens on my phone, and a price that beats the $15 a month I was paying.

While I waited for that, I asked myself a slightly uncomfortable question. Who are these products actually built for?

I was paying for a different user

Look at what the dictation apps compete on. Polish that removes your “umms” and fixes your grammar. A tone setting per app, so Slack sounds casual and email sounds formal. Remembering the names of your contacts so they are spelled right. Formatting lists. Matching your writing style.

Every one of those features makes sense for a specific user: someone dictating text that another human being is going to read. An email to a client. A message to a colleague. A reply on LinkedIn. That user needs the output to be clean, because the output is the final product.

That is not me, most of the time. When I went back through what I actually dictate, the overwhelming majority of it is instructions to an agent: a Claude Code session, my personal assistant on Telegram, a spec for something I want built. And agents are a very different reader.

An agent does not care about my spelling. It does not care if I start a sentence, abandon it, and start again. It understands intent from messy, half-formed speech remarkably well, often better than a human would from the same transcript. What it needs from me is not polish. It needs the thought, quickly, before I lose it.

So I was paying a monthly subscription mainly for features I had no use for, for a reader who does not need them, in a product whose roadmap is decided by the needs of a much larger crowd of people writing emails. That is a perfectly good product. It is just not mine.

There is an old joke about Microsoft Word: everyone uses only five percent of it, but it is a different five percent for each person. Dictation apps are the same. dictum is just my five percent, built on its own, with the other ninety-five left out.

It was never about the $15

I want to answer the obvious objection before you raise it. I pay $200 a month for my Claude subscription. I have written a whole post about whether that is worth it. Arguing over $15 a month would be silly.

It is not about the money. It is about two other things.

Control. When I want a feature, I want to build it this week, not hope it appears on someone’s roadmap next year. When a feature gets in my way, I want to delete it.

Privacy. A dictation app hears everything I say to my agents: half-finished ideas, work context, family logistics. I would like as much of that as possible to never leave my own machines, and where it has to, I want to know exactly which provider sees it and under what terms.

The money is the third reason, and it turned out to be a pleasant surprise, which I will come to.

What I actually need

When I wrote the requirement down, it was short.

1. Speech to text, and almost nothing else. English first. Hindi later, when I find a model I trust.
2. On both my devices. Roughly 60 percent of my dictation happens on my Android phone and 40 percent on the Mac.
3. A thin layer over a good open model. Whisper is excellent and it is free to run. The app around it should be small.
4. My own words. A dictionary of the names and jargon I use (sathi-cli, Tailscale, Claude Code, my kids’ names) so they come out right every time, shared across both devices.
5. Polish as a switch, off by default. For the rare email, I turn it on. For my agents, it stays off.

There was nothing on the market shaped like that. So, with Claude Code doing most of the typing, I built it.

How dictum works

The whole design fits in one sentence: speech becomes text locally where the hardware allows it, in the cloud with my own key where it does not, and everything clever on top of that is optional.

Here is what happens to a single dictation, on either device, from the moment I start speaking to the moment the text appears:

And the same thing as a table, which is how I actually think about it:

Job	On the Mac	On Android
Speech to text	Whisper large-v3-turbo, local, on Apple Silicon. Audio never leaves the machine.	Whisper large-v3-turbo through OpenRouter, with my own key and zero data retention.
My vocabulary	The dictionary lives and is edited here.	A copy is pulled from the Mac mini over Tailscale.
Polish (optional, off by default)	gpt-oss-20b through OpenRouter.	The same model, the same way.
The future intelligence layer	An open model in the cloud, through OpenRouter.	The same.

On the Mac: the model runs on my own chip

On the Mac, speech never leaves the machine. dictum runs Whisper large-v3-turbo on the Apple Silicon GPU through MLX. The model is about 1.5 GB, it downloads once, and then it stays loaded. On my M4 Mac mini, a seven-second clip comes back as text in under two seconds, which is fast enough that I stopped noticing it. The same happens on my MacBook, on the laptop itself.

You hold a key, speak, and let go. The text lands wherever your cursor is, in any app. A small bar at the bottom of the screen shows that it is listening.

That bar is a good example of what bespoke gets you. When I first started with Wispr Flow, its bar sat fixed at the bottom centre of the screen, right on top of my Dock. It covered the icons behind it, and I could not click them. For something I used all day, that was genuinely irritating, and for a long time there was no way to move it. They eventually added the option to dock it to a different edge of the screen, which helped. In dictum, the bar is simply draggable: pick it up and put it anywhere, move it again whenever it gets in the way. It took a few minutes to build and it is exactly the behaviour I wanted. Nobody had to prioritise it for me.

On Android: one hop, my own key

Phones are a different problem. Running a large Whisper model on a phone is possible, but it is slow and it eats the battery, and I wanted the same quality on both devices.

So on Android, dictum sends the audio to the same Whisper model through OpenRouter, which lets me choose the model and the provider and insist on zero data retention. The API key is mine, pasted once into the app and stored in the phone’s hardware-backed keystore. There is no dictum server in the middle, no account, and no company in between holding my audio. It is one request from my phone to the model I chose.

The interaction copies what I liked about the big apps. When I tap into any text field, a small floating mic bubble appears at the edge of the screen. Tap to start, tap to finish, or hold it and talk. The text is typed straight into the field at the cursor through Android’s accessibility input API, the same way a keyboard would type it. Password fields, number fields and banking apps are excluded on purpose. Drag the bubble onto a target and it snoozes for ten minutes; a shake brings it back.

The dictionary: synced over my own tailnet

The part I enjoyed designing most is the dictionary. I curate it on the Mac, where I do most of my editing. Every time it changes, the Mac writes it out as a small file into a folder that is served only on my Tailscale network, and the phone pulls it from there.

So there is no cloud sync service, no account, and nothing exposed to the public internet. My phone and my Mac mini are on the same private network wherever I am, so syncing a word list between them is just a file fetch.

The dictionary is used twice on each device. It goes to Whisper as a hint, so it is more likely to hear “sathi-cli” rather than “Sati CLI” in the first place. Then, after transcription, a plain deterministic pass applies my replacements and snippets, so a mistake that slips through still gets fixed. No model is involved in that second step.

Insights: one set of numbers for both devices

Wispr’s stats page was the thing that told me I had spoken 130,000 words in a month, and I did not want to lose that. So dictum keeps an Insights page on the Mac: words, words per minute, hours of audio, the apps I dictate into most, and what each dictation cost. Both home screens above show the headline numbers.

The phone records the same things for every dictation, including the exact cost of each cloud call, but today those rows stay on the phone, so the Mac only sees the 40 percent of my usage that happens there. The next piece is a small sync endpoint inside the Mac app, reachable only over Tailscale: every fifteen minutes, and right after each dictation, the phone pushes its usage rows up and pulls the latest dictionary down, and anything it has learned about my vocabulary arrives on the Mac as a suggestion I can accept or dismiss. If the phone is off the tailnet for a day, the next sync just carries a bigger batch. Then Insights shows one combined picture, with a Mac and Phone split, and the dictionary flows both ways on the same private line.

Why polish is a switch, and why it is off

Polish exists, because sometimes I do dictate an email. When I switch it on, the transcript goes to gpt-oss-20b, a small open model, through OpenRouter, with instructions to clean up the text without changing what I meant. It comes back in under a second, and if it fails for any reason I get the raw transcript rather than nothing. I deliberately do not run a polish model locally: a small cloud model is faster and better than anything I would want sitting in my Mac’s memory all day, and at these prices there is no reason to.

It is off by default for three reasons. My agents do not need it. It adds a second network call, so it adds latency. And it is one more place my words go. Most days it stays off, and my agents get exactly what I said.

What it costs

This is where it got interesting, so I did the maths properly, using my real usage.

My usage. In my busiest recent month I dictated about 130,000 words. At my speaking pace of about 163 words a minute that is roughly 13 hours of audio. I will round it up to 15 hours a month to cover the pauses, the false starts and the clips I throw away.

The prices. On OpenRouter, Whisper large-v3-turbo costs between $0.012 and $0.04 per hour of audio, depending on the provider. I will use the higher one. Polish with gpt-oss-20b costs about $0.00006 per call. The Mac’s local Whisper costs nothing extra: my Mac mini runs 24/7 anyway, so I am not counting its electricity.

The worst case. Pretend every word goes through the cloud, even the ones I say on the Mac, and that I polish every single dictation, about 2,600 a month:

• speech to text: 15 hours × $0.04 = $0.60 a month
• polish: 2,600 calls × $0.00006 = $0.16 a month
• total: about $0.76 a month

The realistic case. About 40 percent of my dictation happens on the Mac, where it is free, and I polish perhaps one dictation in ten. That comes to roughly $0.40 a month.

Now stretch it out over five years, assuming my usage stays where it is:

	Per month	Per year	Over 5 years
Wispr Flow at $15 a month	$15.00	$180	$900
dictum, worst case	$0.76	about $9	about $46
dictum, realistic	about $0.40	about $5	about $24

That is a difference of roughly $850 to $875 over five years, for one app, at one person’s usage. The $10 of credit I put on OpenRouter covers more than a year even in the worst case, and closer to two in the realistic one.

To be fair to the subscription, $15 a month is not expensive for what it is, and there is a real cost to my approach that does not show in that table: my time. But the time is the part I actually enjoy, and I will come back to why it pays for itself in a different way.

Where this goes next

Here is the part that actually excites me, and the real reason to own the software instead of renting it.

Personas, not polish. “Polish” is a crude idea. It assumes there is one correct way to clean up my words. There is not. dictum already knows which app I am dictating into, on both the phone and the Mac. So instead of a single polish switch, I want small personas behind the scenes, each a prompt and a set of rules for an open model running in the cloud through OpenRouter, the same way polish works today. No local model to babysit, and I can swap in a better one whenever it appears:

• When I am writing to my wife, it should keep my tone, keep the jokes, and quietly remove the words I would not actually say to her.
• When I am writing a work email, it should restructure my rambling into something crisp and professional, without inventing anything I did not say.
• When I am talking to an agent, it should do nothing at all.

That last one is a design decision, not laziness. When I talk to an agent, I want it to hear how I talk. If I repeat an idea three times in three different ways, that is not noise to clean up. That is emphasis. It is the same signal a person picks up across a table: when someone keeps coming back to a point, you know it matters to them. A polishing step would compress my three attempts into one tidy sentence and throw that signal away. The raw transcript, ums and restarts included, carries more of my intent than the clean one.

Memory. Today the dictionary is a list I edit. I want it to become something closer to memory: the people I mention, the projects I am working on, the phrases I use with different people, learned from what I dictate and how I correct it, and shared across my devices. On the Mac, dictum already notices when I fix a word right after it is typed and learns it as vocabulary. That is the seed. The grown-up version is one intelligence layer that knows my taste and my style in every app, on both devices, sitting between my voice and wherever the words are going.

Hindi. My parents get voice messages from me in Hindi. When I find an open model that handles Hindi well, it goes in.

None of these features are on anyone else’s roadmap in the shape I want them. They do not need to be. They are on mine.

“But who maintains it?”

This is the objection I hear most, and it is the same argument people make inside companies about building rather than buying: you will drown in maintenance.

For an app with an audience of one, I do not buy it. dictum is a thin layer over a model somebody else maintains. When a better speech model appears, I change one line of configuration and get it. When Android or macOS changes something underneath me, I describe the problem to an agent and it gets fixed. And nothing about it is urgent: there is no customer waiting, no SLA, no on-call. If it breaks on a Tuesday, I fix it when I feel like it.

More importantly, I think maintenance is the wrong frame. The real return on building your own tools is not the subscription you cancel. It is what the building does to you.

From product-market fit to product-use-case fit

For as long as software has existed, the only way to make a product viable was to find a large enough group of people with the same problem. Product-market fit. That is why every product you pay for is shaped the way it is: general enough to serve a mass audience, with your particular needs averaged in among everybody else’s. The features you care about are rarely the ones on the roadmap, because you are one user among many and the roadmap follows the many.

That constraint is loosening. On a recent episode of the All-In podcast, David Sacks made the point that software used to be created only for the mass market, because that was the only kind that could pay for itself, and that coding assistants have opened up “this new category” of bespoke software for highly specific use cases, which he expects to be “a huge driver of productivity throughout the economy”. Someone else on the show called it the Jevons paradox of software: the price of software goes down, and the amount of it goes way up. They were talking about enterprises building their own tools instead of buying them. I think the exact same logic now applies to one person.

So I have started thinking in terms of product-use-case fit instead. Not “is there a market for this?” but “does this fit precisely how I work?” dictum will never have product-market fit. It has, for one user, perfect product-use-case fit, and that was impossible to afford before.

My use case is nothing like the typical Wispr Flow or Kivi user’s, and that is fine. Theirs is a good product for their users. Mine is a good product for me. The difference is that I no longer have to accept a product built for several kinds of users at once when I can have one built for exactly one.

Building is how you develop taste

People say taste is the scarce skill now that AI can execute almost anything. I agree, and I think taste works the same way it does with food. You do not develop a palate by eating the same dish every day. You develop it by trying many cuisines, many dishes, many ways of doing the same thing, until you can tell what is good and why.

Software is the same. Every product I build teaches me something the previous one could not: a different architecture, a different trade-off, a different failure. dictum taught me about on-device models, Android’s accessibility system, how to keep audio private, and how little of a “product” a person actually needs. The next one will teach me something else. Each one widens what I can imagine, and that compounds.

And because I own it, I can take dictum in any direction. Every one of these apps exists for the same reason: personal productivity. If you know what makes you productive, the hacks that work for you specifically, then you are the best person in the world to design the tool for it. The execution is no longer the hard part. Think it through, plan it, write a clear spec, and let the AI build it. The thinking is the part that is still yours.

Pick one subscription

A year ago, building a cross-platform dictation app for an audience of one would have been absurd. You paid the subscription and bent your workflow around the product, because the economics left no other option.

That has quietly changed. With an agent doing the execution, a small, personal, well-designed app costs a few focused sessions of thinking. And what you get is not just the subscription you cancel. It is software that fits you, instead of the median user of somebody else’s product, on a roadmap you set.

So here is my suggestion. Look at the subscriptions you pay for and ask one question of each: am I actually the user this was built for? If the honest answer is “only partly”, that might be your next weekend project.

I will keep building dictum, and I am planning a video about bespoke personal apps more broadly. If you have built something like this for yourself, I would love to hear what it was.