Konect: audio transcription and analysis
Organizations accumulate hours of audio —calls, recordings, voicemail inboxes— that nobody can consult. Konect turns that audio into analyzable, searchable text.
I worked on the Irontec team that built the platform, as software architect and platform architect: defining the event-driven architecture, the hybrid search and the per-customer deployment model.
What Konect is
Konect was born in the Irontec communications department, which operates VoIP telephone switchboards for several customers. The goal was to equip a service as traditional as telephony with custom transcription and analysis features.
Calls, recordings, emails and documents all come in through the same log, and the platform does the rest: transcribe, analyze, index and search. Every conversation is classified by category, with its sentiment analysis. On top of that: an API, a web application, a mobile app and a reporting system.
It is not a one-off transcription service: it is a platform designed to be operated as a SaaS, where each customer works on their own isolated instance.
Job- and event-driven architecture
Everything revolves around a job: the unit of work that represents something to be processed —a call, an email, a document—. Each job declares its own pipeline in a recipe:
- API ingestion.
- Transcription.
- AI analysis.
- Indexing for search.
A pipeline router chains the steps through the queue, and every state change emits a domain event —JobCreated, AnalysisCompleted and about twenty more— that keeps the system decoupled.
The key to adapting to each customer without breaking the product is that jobs are composable: all customers share the generic job that runs the main analyses, and when someone asks for something custom, a specific job is programmed that hooks into the same messaging protocol over Redis. The custom logic stays contained and isolated, outside the core —the worker that categorizes one customer’s documents is the example: it listens to the events and applies that sector’s own categories without touching the shared pipeline—.
The backend is Python with FastAPI, organized with DDD and separated commands and queries (CQRS). Heavy jobs run in Taskiq workers on Redis Streams, selectively scalable by task type.
Multi-provider transcription
No single speech provider is the best at everything. The platform integrates four and lets you choose per job:
- Deepgram, with diarization and a dozen languages.
- Whisper, served through the model gateway.
- Google Cloud Speech.
- Trebe, an STT provider in Basque.
A model gateway with LiteLLM
All access to AI models goes through an in-house LiteLLM gateway. That gives you three things: stable aliases for STT, analysis and embeddings —switching models never touches the product code—, per-model cost accounting and, together with Langfuse, prompt tracing and observability.
Vector search with pgvector
Every transcription and analysis is indexed in PostgreSQL with pgvector: embeddings in halfvec columns with HNSW indexes for semantic search and tsvector in Spanish for full-text. Hybrid search without leaving the database.
Identity and access: OIDC and RBAC
Konect does not manage passwords: it delegates identity to Keycloak via OIDC. Roles travel in the token and the platform enforces real RBAC —the konect-admin role unlocks administration in both the API and the interface; all other users are limited to their own work—, plus system tokens for machine-to-machine integrations.
Platform: Kubernetes, GitOps and preview environments
Infrastructure is versioned just like the product. A dedicated GitOps repository feeds a Kubernetes cluster synchronized by ArgoCD in app-of-apps mode:
- Devcontainers so the whole team develops on the same environment.
cert-managerwith Let's Encrypt wildcard TLS via Cloudflare.- Secrets in Infisical, injected with External Secrets Operator.
- Harbor as a private registry for images and charts.
- CI on
Jenkinswith backend and frontend tests running in parallel.
The detail I like the most: every pull request automatically spins up a full preview environment that replicates the staging environment and copies its data. Reviewing a change stops being a leap of faith.
RBAC + multi-tenancy
Each customer operates their own deployment: their own Kustomize overlay, their own Keycloak realm, their isolated data and, when needed, workers dedicated to their logic —like the document-categorization one. RBAC inside the application and multi-tenancy per deployment: that is how the platform is sold and operated as a SaaS.
From data to report
Results do not stay in the database. An MCP server exposes search, facets, aggregations and charts as tools; an embedded chat uses them to answer questions about the content; and reports are downloaded as .docx.
Conclusions
Konect shows that the recording → text → analysis → answer pipeline fits in a single platform, operated as a multi-tenant SaaS without sharing data between customers.
On a personal level, this project has allowed me to dive deep into Kubernetes —not as an exercise, but operating the real platform—. And many of the technologies we implemented here (GitOps, our own registry, secrets management, preview environments) have consolidated a very solid understanding of what it means to build platforms as a service.
More real-world cases
Classifying documents into 77 categories without training a model
LLMOps on your own cluster with LiteLLM, Langfuse, and ArgoCD
Applied AI consulting for business
From standard to graph to project
Setting up a homelab from scratch: backups and restore - Homelab (06/06)
