What I cut from v1

A useful exercise when you ship anything indie is to write down what you cut. The cuts are where the product is, more so than the features. Everyone ships a feature list; cutting is the harder act and the one that produces the shape.

This is a partial list of things Voiacast v1 does not do, and the reason each one stayed cut. Some of them will land in a later release. Some will not. The “will not” cases are not failures of ambition; they are the constraints that produced the product.

Meeting transcription

Voiacast does not capture system audio. It does not transcribe the other side of a Zoom call. It does not produce a post-call document of who said what.

The reason is that meeting transcription is a different product. It has a different permission surface (screen recording, not microphone), a different storage shape (a document, not a stream of keystrokes), and a different threat model (recording other people’s voices, with all of the legal and ethical weight that carries). Bolting it onto a dictation tool would compromise both.

Meeting transcription is a plausible v2-or-later product. When it ships, it will ship with its own permission flow, its own settings surface, and its own privacy story. It will not silently leak into the dictation product.

Cloud-synced custom dictionary

The dictionary in v1 is a local file. There is no Voiacast cloud syncing it across machines. The Pro tier ships export and import; the manual loop is the syncing mechanism.

The reason is that the dictionary is the most sensitive piece of data the product produces. It is the names of your clients, the codenames of your projects, the acronyms your team uses. A cloud-synced dictionary is a cloud-synced list of what you actually work on. I do not want to be the custodian of that list, and I do not want a user to have to ask whether I am.

Could a future Pro feature ship an end-to-end-encrypted sync that addresses the concern? In principle, yes. The honest answer for v1 is that the manual export/import pattern is enough for a working team and that the cryptographic engineering required to ship a real E2E sync is not the right time spend at v1.

A login, a profile, an account

Voiacast does not have an account model. There is no email/password combination, no profile page, no preferences-saved-to-a-server. The license key is the only thing tying a user to their copy of the app.

The reason is that an account model is a one-way ratchet. Once you have one, the product surface grows around it — forgot-password, MFA, session management, support tickets, account-deletion flow. None of those add anything to the dictation experience. They add a lot to the operational surface I would have to run forever.

If a user-facing feature genuinely requires accounts — multi-device sync of preferences, team admin, a forum — we will revisit. None of those are in v1.

Telemetry by default

Voiacast ships no analytics by default. There is no “phone home” call the first time you launch the app, no event stream of the words you dictated, no anonymous usage report. There is an opt-in toggle for anonymous crash reports.

The reason is the same as the privacy argument elsewhere: an opt-in default is harder to misconfigure into a leak than an opt-out one. There is also a more selfish reason: a tool that quietly ships telemetry is a tool the user has to read the privacy policy of every time it updates. A tool that ships none does not have that problem.

Built-in checkout

Voiacast does not ship an automated checkout. Donations route through PayPal and the license arrives by email within two business days, manually, from a human reading the donations inbox.

The reason is that an automated checkout is a feature with a long tail of operational cost. Webhook retries, refund handling, chargebacks, fraud, tax reporting, multi-currency. The manual loop costs a few minutes per donor and holds up perfectly well at indie scale. When the volume passes the point where the manual loop is the bottleneck, the checkout will land. Not before.

A Windows build

Voiacast is Mac-native. There is no Windows build. There might not be a Windows build for a long time.

The reason is that “Mac-native and Windows-native” is two products shipped under one name, and the native parts of each — the Accessibility API, the global hotkey, the menu-bar UI — are fundamentally different on the two platforms. A cross-platform abstraction layer would compromise both. The honest answer is that when (and if) a Windows version ships, it will be a separate codebase written specifically for Windows.

Live model selection at the keystroke level

You cannot, in v1, hold one hotkey for the small model and another hotkey for the large model. The model choice is a setting, not a per-keystroke flag.

The reason is that per-keystroke model choice is a configuration surface I do not want to expose. Most users do not want to think about which model is dictating which sentence; they want the right answer to land in the field. Pro adds a model picker; the model is the model until the user changes it. Power users can do the rest.

What I want to leave you with

A product is the cuts. The features are the bait the cuts produce. Every line in the bulleted list above is a thing somebody, someday, will ask Voiacast to do. The honest answer for many of them is “not in v1, and possibly not at all”. That is fine. The thing that earns trust from the people who pay for indie software is the discipline of saying so, not the volume of features shipped.

The dictation that the product does ship — push-to-talk into the focused field, on-device by default, with a local dictionary — is small enough to be the right answer for the people who would buy it. The rest is for later, or for somebody else.