FastScribe Reviews — Discover what people think of this product.

I run a transcription SaaS. The obvious build is a web form in front of a cloud speech API, and I started there on paper. The arithmetic killed it.

Per-minute API pricing means a free tier is a direct subsidy. Every free file is money out. So every competitor's free tier is either tiny, or gated behind an account so they can throttle you, or both. That is not greed, it is the cost structure showing through the pricing page.

I already had a server. I put a GPUs in it. Now the marginal cost of a transcription is electricity, which changes what I am able to offer: the first file needs no account at all, and 5 a day free with one. I am not subsidizing anything, I am using capacity I already pay for.

The measured part, since numbers are the only interesting bit of a story like this: moving transcription from CPU to that GPU came out at roughly 55x real-time on the model I use, and about 105x on a smaller one. A one-hour recording finishes in about a minute. On CPU it was slower than listening to it.

What this actually costs me, honestly:

• One machine. No redundancy. If it dies, the queue stops and I get an alert.
• I own the ops. Fan curves, ECC errors, thermal alerts. I have a cron job that texts me if the GPU gets hot. A cloud API user has none of this.
• It does not scale past this box without me buying another one, and I would have to want that.

The second-order effect showed up this week, and it is the part I did not see coming. I added speaker labels. On a cloud speech API diarization is a separate line item, billed per minute on top of the transcription, which is why free tiers almost never include it. On my own box it is a second model on the same GPU. The marginal cost went from electricity to slightly more electricity, so I could put labels on the free no-signup file instead of holding them behind the paywall where the cost structure would have forced them.

That is the argument for owning the hardware, restated: it is not that the first feature is cheaper, it is that the tenth feature is possible. Each thing I add costs GPU time I have already bought rather than a new per-minute rate I have to price into a plan.

The bill for it was ops, not money. pyannote needs torch, which I did not want anywhere near the worker's dependency tree, so it runs in its own venv as a subprocess. One GPU cannot hold whisper and pyannote at once, so runs take a lock and queue behind each other. Nobody sends you that in an API response.

What I would tell someone considering the same thing: this only works because the workload is batch, not interactive, and because I already had the machine and the ops habit. If you would be buying a server to avoid an API bill you have not yet received, do not. The API is the right call until the bill hurts.

The privacy consequence was accidental and turned out to be the best thing about it. Because there is no third-party API in the path, I can say the audio never reaches OpenAI, Google or AWS, and I delete it the moment the transcript exists. Competitors whose business model needs an account cannot copy the no-signup claim, and competitors who forward audio to a cloud API cannot copy the privacy one. I did not plan that. I backed into it by being cheap.

Site is thefastscribe.com if you want to break it. Happy to go into the hardware or the queue design.