Our team was spending ~$8,500/month on tl;dv for 200 engineers. We moved to Otter.ai, cutting that cost by ~82%. The migration wasn't trivial for a Kubernetes-based deployment.
**Primary Cost Drivers & Solution:**
* **tl;dv Pricing:** Per-seat, per-meeting model scaled terribly with daily stand-ups, planning, and ad-hoc design sessions. At our volume, it was unsustainable.
* **Otter.ai Model:** We use their Business API ($0.30/audio minute, volume discounts). We built an internal service to handle transcription routing.
* **Monthly Spend:** Went from $8,500 to ~$1,500. This includes our compute overhead for the routing service.
**Deployment Architecture & Gotchas:**
We run in EKS. The core component is a lightweight Node.js service that:
* Listens for Google Meet/Teams webhook events (via Google Workspace/MS Graph).
* Fetches the meeting audio file.
* Pushes it to Otter.ai's API for transcription.
* Stores the result in our internal wiki system.
The main challenges:
* **Audio File Handling:** Otter.ai's API requires a direct download URL. We had to implement a secure, temporary pre-signed URL pattern from our storage to avoid proxying large files.
* **Idempotency:** Duplicate webhook events are common. Our service needed deduplication logic based on meeting ID + timestamp.
```yaml
# Snippet from our Kubernetes CronJob for cleanup.
# Runs hourly to delete processed audio files >2 hours old.
apiVersion: batch/v1
kind: CronJob
spec:
schedule: "0 * * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: cleaner
image: aws-cli-alpine
command:
- /bin/sh
- -c
- |
aws s3 rm s3://our-audio-bucket/ --recursive
--query "Contents[?LastModified<='$(date -d '-2 hours' --utc +%FT%TZ)'].Key"
--exclude "*.txt"
```
**Lessons Learned:**
* The API-based model is far cheaper for high-volume teams, but you own the integration and reliability.
* Latency is higher. Transcripts are ready ~2 minutes after meeting end vs. near real-time.
* Otter.ai's speaker diarization is good, but not quite as accurate as tl;dv in noisy, fast-paced technical discussions. We accept the trade-off for the cost savings.
For teams under 50 users, tl;dv's simplicity might be worth it. At our scale, the build-vs-buy math was clear.
cost per transaction is the only metric
SRE at a fintech with 500+ nodes across three clouds, we run Prometheus/Thanos, Loki, and Grafana for all internal observability. My team built our own meeting transcription pipeline two years ago to cut vendor costs.
**Core Comparison**
* **Cost Model & Predictability:** Otter.ai's API pricing ($0.30/min) wins for high, variable meeting volume. tl;dv's per-seat/per-meeting model creates unpredictable spend for engineering teams with daily scrums and ad-hocs. Your 82% cost cut is consistent; we saw ~75% reduction.
* **Deployment & Maintenance Overhead:** Otter.ai requires you to build and own the integration glue (webhooks, audio routing, storage). That's 1-2 FTE weeks upfront and ongoing SLOs for your service. tl;dv is a managed SaaS, zero infra overhead.
* **Latency & Throughput:** Otter.ai's API averages 1.5x real-time for transcription (30 min meeting = ~45 min processing). At peak (10+ concurrent jobs), we've seen queues add 20+ minutes. tl;dv is near real-time but you hit hard meeting limits.
* **Audio Source Limitations:** Otter.ai's API is strict on format. We had to normalize audio from Webex, which required an extra FFmpeg step, adding complexity and failure points. tl;dv handles varied inputs natively.
**Your Pick**
For a 200-engineer K8s team that can commit to building and maintaining a lightweight routing service, Otter.ai's API is the clear choice for pure cost savings. If your team has zero bandwidth for devops on this, stick with tl;dv. Tell us your average concurrent meetings and your team's tolerance for managing another service's PagerDuty alerts.
Metrics don't lie.
The pre-signed URL pattern for audio is a smart move. We hit a similar snag with Zoom recordings and ended up using a short-lived Azure Blob SAS token. Did you run into any issues with Otter.ai's URL fetch timing out on larger meeting files, or was the default timeout sufficient?
Also, curious about your idempotency handling. For our pipeline, we keyed on the meeting ID plus the recording start timestamp, which covered most retry cases.