A live classroom platform generates a lot of audio. If every minute of every class gets transcribed through a paid API, the transcription bill scales linearly with the thing you actually want to grow: usage. That's backwards for a product that needs to stay affordable as it succeeds.

On Quran Horizon, the alternative was to self-host the transcription pipeline instead of calling out to a paid API for every class. faster-whisper — a reimplementation of OpenAI's Whisper models using CTranslate2 — runs comfortably on a single GPU and processes audio close to real time, which matters when the transcript feeds a teaching-quality evaluation step that runs during or right after class, not overnight.

The real trade-off

Self-hosting isn't free — it trades a per-minute bill for fixed infrastructure cost and the operational work of keeping a GPU service healthy. That trade only makes sense above a certain volume, and it comes with a maintenance cost a paid API doesn't have: you own the uptime.

• Model size is a real lever — a smaller Whisper variant trades some accuracy for meaningfully lower latency and VRAM use
• Batching requests instead of processing one stream at a time keeps GPU utilisation reasonable under concurrent classes
• A queue in front of the transcription service means a burst of simultaneous class-ends doesn't stall the pipeline

Where it stopped being just about cost

Once the pipeline was self-hosted anyway, it became the natural place to add things a third-party API wouldn't let us build: streaming keyword and PII detection during a live class, for instance, with an automatic mute if something flagged appears. That's not a feature you can bolt onto someone else's black-box transcription endpoint — it comes from owning the pipeline end to end.

If your product's usage is genuinely low, a paid API is still the right call — it's less to build and less to operate. The self-hosting decision only pays for itself once volume and product requirements both point the same direction.