Transcription inside your product, without the per-minute bill
The speech model runs in each of your users' browsers. Their audio never reaches your servers, your cost does not grow with usage, and there is no API key to issue. One iframe.
- ✓ No per-minute cost
- ✓ No audio on your infrastructure
- ✓ No SDK, no API key
- ✓ MIT licensed
The argument, corrected by a real reply
The first version of this pitch assumed platforms were missing transcription. A podcast host replied that they "aren't making changes to our transcription tool right now" — they already had one. That is true of any established platform, so the pitch is not "you're missing a feature".
It is this: the transcription you have bills you per minute, and it requires your customers' audio to pass through your servers. The first eats margin that grows exactly as your product succeeds. The second makes you a processor of other people's personal data, with everything that carries. Browser-side transcription does neither, because there is no server in the path at all.
Replacing something that already works is a harder sell than filling a gap. We would rather say so than have you find out in the first meeting.
Barry Krantz, CEO of Blubrry, on The New Media Show: hosting, storage and distribution "have become commodities; competitive differentiation now comes from the tools, services, support, analytics and workflows built around the infrastructure". That is the business problem, stated by the customer.
Try the actual thing, here
Not a video, not screenshots — the same build your users would get, running inside this page. It loads when you ask it to, so reading this page costs nothing.
Drop in any audio or video file. The first run downloads the model and the interface shows real progress; after that it starts instantly and works offline.
The whole integration
<iframe src="https://gate32.autoritasai.com/embed/?lang=en&model=balanced" style="width:100%;height:760px;border:0;border-radius:12px" allow="microphone" title="Transcription" ></iframe>
That is all of it. No SDK, no API key, no server to call.
| Parameter | Values | Effect |
|---|---|---|
lang | en, es | Interface language |
model | fast, balanced, accurate | Fixes the model and takes the choice away from the user |
brand | 0 | Hides the Gate32 attribution line |
allow="microphone" is only needed if you want your users to record directly; for
transcribing files it is not.
What your user gets
They drop a file, the model downloads once, and they get text with per-sentence timestamps, editable, exporting to TXT, Markdown, SRT, VTT and JSON. Subtitles come out already wrapped to 32 (CEA-608), 37 (BBC) or 42 (Netflix) characters per line. Lines the model is likely to have got wrong are flagged, and clicking one plays that moment of the audio.
⚠️ What to tell them, and not hide. The first run waits for the model to download. Without WebGPU it is much slower. It does not separate speakers yet. Very long files can fail on browser memory — an episode over an hour on a modest machine is the practical limit. Tab capture needs desktop Chrome or Edge.
One person builds this. Here is why that is not your risk
Gate32 is built and maintained by one person. For anyone about to rest a feature of their product on someone else's work, the first reasonable question is: what if this disappears?
The answer is the licence. MIT, complete public source, no backend. If this were abandoned, your team keeps a static build that goes on working — clone it, serve it from your own domain, modify it, no permission needed. There is no server to switch off, no API to cut, no key to expire.
Compare that with integrating a cloud transcription service, where a shutdown or a price rise does leave you without the feature. Here the worst case is that you stop receiving updates to something you already have.
So what is there to pay for? What the licence does not give you: a maintained build tested against browser and model changes, integration support, and priority on the features you need.
Talk to the person who builds it
No sales team, no demo booking form. Write and you get an answer from the person who wrote the code: hpartida@autoritasai.com, or open an issue on GitHub.
Useful things to include: what your users transcribe, roughly how many minutes a month go through your current provider, and whether you need it in a language beyond English and Spanish.