Long videos and recorded conversations — turned into short, structured documents
This is a case study: an example of how I design and deliver AI integrations. Transcriber takes a long video or audio recording — a YouTube lecture, a work meeting, an interview — and returns a finished document: a digest, key points, or clean text.
The service runs on my own GPU — I use it daily myself; it is publicly available and free for now. Architecture, backend, ML pipeline, infrastructure, deployment — all built by one person.
The problem
You probably know the situation: a two-hour YouTube lecture you never find time to watch; a meeting recording nobody will ever replay; an interview that has been waiting a month to be transcribed. Re-watching is slow. And a raw transcript is not the answer either: 90 minutes of conversation becomes one long, unstructured block of text that is hard to work with. What you need is not a transcript but a document — short, structured, searchable.
There are two more requirements. Media files are often confidential — uploading them to someone else’s cloud is not an option, or simply not something you want to do. And the volumes are large: online transcription services charge per minute, which becomes expensive fast with regular use. So Transcriber is built differently: the heaviest work — speech recognition — runs locally on my own GPU, and only the transcript text ever leaves the server. In a client project this can go even further: the language model can also run locally, so no data leaves your infrastructure at all.
How it works
Adding a recording
Two ways to add a recording: upload a file — audio or video (web interface, drag-and-drop) — or paste a link (YouTube and other sites are supported via yt-dlp). The audio track is extracted from the video; ffmpeg converts virtually any format into whatever the pipeline needs.
Transcribing
Speech is recognized by a local model — faster-whisper(large-v3-turbo) — on my own GPU inside a CUDA container. An hour-long video takes about 10 minutes on a regular consumer GPU; progress is visible live — percentage complete, speed, time remaining. The only real running cost is electricity: about 0.03 kWh per hour of recording — a fraction of a cent.
Structuring (the LLM stage)
The transcript goes to a large language model (LLM) — Claude — with a template for the task: clean the text of filler words and verbal slips, compress it into key points and decisions, or expand it into a detailed digest — or run the user’s own prompt; the output can be in any of more than 25 languages. A template is a “prompt + output format” pair: a new document type can be added without touching the code.
Getting the result
The finished document can be downloaded as TXT, Markdown, PDF, or DOCX — with the raw transcript and the original audio always stored alongside it. Registered users keep a personal list of their files, and the result can optionally be sent by email.
Engineering decisions
An LLM failure never destroys finished work
An LLM failure is part of the design, not an emergency. If text processing fails even after retries, the user still gets the raw transcript and a “process again” button — the expensive GPU work is never lost to a failure in a later stage. Planning what happens on failure, before building the main flow, is the core of real LLM integration.
The cost is known in advance
The most expensive operation — speech recognition — runs on my own hardware, so the only real running cost is electricity. The paid Claude API receives only text, never media files; the input size is known from the length of the recording, and the built-in templates cap the output — so the cost of a run can be estimated up front. Costs stay predictable even as usage grows.
One image, one deployment
.NET handles the API, the job queue, file storage, and user profiles; Python does only the ML part (faster-whisper). Everything lives in a single multi-stage Docker image — CUDA + .NET + Python, with GPU access for the container. No microservices where they are not needed: one person can understand the whole system and change it in hours.
Live progress instead of a silent spinner
Long GPU jobs report their progress: the Python worker sends structured events — percentage complete, speed, time remaining — to .NET, and the client polls for status updates. The user sees that work is progressing — no guessing whether the job is stuck, no anxious page refreshing.
Stack
Result
A working service on my own GPU: web interface, publicly available, and free for now.
Three built-in processing templates plus a custom prompt; a new document type can be added without touching the code.
An hour-long video is transcribed in about 10 minutes; the electricity cost is a fraction of a cent per hour of recording.
Currently all transcription is local: media files never leave the server — only the transcript text is sent out.
Known limitations and next steps
I deliberately launched the service early, without waiting for it to become “perfect”. Below are the system’s known limitations and the plan for addressing them. I approach client projects the same way: a working system first, then scaling when the real load demands it.
The job queue currently lives in memory: jobs still waiting in the queue when the service restarts are lost (finished transcripts and documents are stored on disk). The next step is a persistent queue.
When my own GPU is no longer enough: a job dispatcher will route some transcriptions to cloud services — only with the user’s explicit permission; confidential recordings will always be processed locally.
Billing via Paddle (a payments platform): minimal pricing that covers running costs.
A flexible choice of language model: the tier will depend on the plan, a backup model will take over automatically if the primary one fails, and, for a fully closed loop, a local open-source model such as DeepSeek-R1 or Llama.
Single sign-on across my whole ecosystem of services: my own authentication module built on the ABP framework (OpenID Connect), with Google or Facebook login.
Where this pattern repeats
The same pattern carries over almost unchanged: incoming data → heavy processing → an LLM stage with a template → a structured result. A few examples:
Sales or support calls → meeting notes, quality control, CRM records.
Work meetings → minutes with decisions and action items.
Podcasts and webinars → articles, digests, social media posts.
An archive of interviews or lectures → a searchable knowledge base.
Incoming documents — PDFs, scans, letters → structured data in your system.
Do you have recordings, videos, or documents you need turned into something useful?
Describe what you need in your own words. I will design the processing flow for your product — from incoming data to the finished result, with predictable costs and no surprises when something fails. We will work out the technical details after the first conversation.