Table of Contents
Some products come from market research. Some come from personal pain points. This one came from a fan message. A tech YouTuber with a significant following received a comment: “I’d love to ask you questions on YouTube, but I have social anxiety — even typing feels stressful, let alone a real call.” He decided to do something about it — not write an advice post, but actually build a product.
This article traces the technical architecture of an “AI-assisted video calling” product, and the engineering decisions an indie developer makes with limited resources.
TL;DR
- Target user: People with social anxiety who want to practice real conversation but are afraid of real human interaction
- Core feature: AI plays a conversation partner, providing real-time voice responses in a video call interface simulating a real conversation
- Tech stack: WebRTC video streaming + real-time ASR (speech recognition) + LLM + TTS (speech synthesis) + AI avatar (Tavus or HeyGen-type service)
- Biggest challenge: End-to-end latency must stay under 800ms for conversation to feel natural
Background and Challenge
Social Anxiety Disorder affects approximately 7% of adults globally, with excessive fear of judgment as its core symptom. This makes many people feel extreme stress during in-person communication or video calls.
Traditional solutions involve cognitive behavioral therapy (CBT), with exposure therapy as a core method — gradually exposing patients to anxiety-inducing social situations. The theory is sound, but there are real-world problems:
- Therapist appointments are expensive with long waitlists
- Practice opportunities are limited (you can’t find a real person to practice with every day)
- Failure cost is high (failing with a real person may reinforce anxiety)
The AI video calling hypothesis: provide a “low-risk practice space” — the conversation partner is AI, so you can restart if you mess up, with no one judging you.
Solution Design
Core UX Assumptions
A successful AI social anxiety practice tool needs to satisfy:
- Visual realism: It should look like a real person talking, not a text box or disembodied voice
- Low enough latency: Response delay over 1 second breaks the rhythm of conversation
- Natural conversation: AI must understand context and not forget what was said earlier
- Sense of safety: Clearly tell users this is AI — don’t make them feel deceived
Technology Stack Choices
Video Streaming: WebRTC
Browser-native WebRTC support, no app install required. P2P connection latency is low — under 50ms in the same region under optimal conditions.
For an indie developer, self-hosting a WebRTC signaling server + TURN server costs significant effort. More practical choices are managed services:
- Daily.co: $0.004/participant-minute, has SDK, fastest to ship
- Livekit: Open source, self-hostable, higher free tier
- Agora: Enterprise-grade, stable but more complex pricing
AI Avatar: Giving AI a Face
Options for making AI visually present break into tiers:
Option A (simplest): Static avatar + audio. AI is a still image that doesn’t move its mouth, only has sound. Easiest to implement, but poor user experience.
Option B (medium): 2D avatar + lip sync. Use Ready Player Me or TalkingHead.js to map audio waveforms to mouth animations. Low cost, but looks like a virtual YouTuber rather than a real person.
Option C (most realistic): AI-generated real-time video stream. Tavus and HeyGen provide this type of API — upload a real person video as a base, and the API generates a speaking video stream in real time with speech matching your text or voice input. Latency runs 300–800ms, and results are closest to a real person. Tavus’s Conversational Video Interface (CVI) is purpose-built for this scenario.
For indie developers: validate with Option A/B first, upgrade to Option C once you have enough users.
Real-Time Speech Recognition (ASR)
User speaks → converts to text → sends to LLM. Speed and accuracy are both critical.
- Whisper (OpenAI): High accuracy, but real-time streaming latency is 500ms+
- Deepgram: Optimized for real-time streaming, latency under 200ms, API pricing at $0.0059/minute
- AssemblyAI: Middle option with speaker diarization capability
Indie developer first choice: Deepgram or AssemblyAI’s real-time API.
LLM Response Generation
Once ASR has the text, send it to an LLM for response generation. Latency-sensitive, so you want fast models:
- GPT-4.1 (OpenAI): Fast time to first token, good for streaming output
- Claude Haiku 3.5: Low latency, low cost, smart enough for conversation handling
- Gemini Flash: Google’s low-latency option
The LLM layer also needs carefully engineered system prompts to simulate specific conversation scenarios (job interview practice, asking for directions, calling someone on the phone) and control response pacing and tone.
Text-to-Speech (TTS)
LLM outputs text → convert to speech → play for user.
- ElevenLabs: Best audio quality, supports real-time streaming, many voice clone options
- OpenAI TTS: $15/million characters, decent quality, simple API
- Play.ai: Designed for conversation, supports emotional tone adjustment
Implementation Details
End-to-End Latency Budget
User finishes speaking (VAD detects silence)
→ ASR recognition: ~200ms (Deepgram)
→ LLM first token: ~300ms (Claude Haiku)
→ TTS first audio chunk: ~200ms (ElevenLabs streaming)
─────────────────────────────────────────
Total: ~700ms
700ms is near the acceptable edge. When any link encounters latency (network fluctuation, LLM load), it exceeds the ~1 second “natural feel” threshold. This is the hardest engineering problem in this type of product.
VAD (Voice Activity Detection)
Must accurately detect “user finished talking” before sending to ASR. Triggering too early (user is still talking) causes the AI to interrupt; triggering too late increases latency. WebRTC has built-in VAD; you can also use Silero VAD (open source, high accuracy).
Conversation Memory Management
Multi-turn conversation requires remembering context, but LLM APIs are stateless — you need to manage conversation history yourself. Strategy:
- Keep the last N turns in full
- Summarize earlier turns (compress token usage)
- Store important facts in a vector database (Pinecone, Supabase pgvector)
Market Context
AI companion apps globally crossed 220 million downloads in 2025, with the number of AI companion apps growing 700% in two years. Born (the company behind virtual pet Pengu) raised a $15 million Series A in 2025 specifically for social AI companions.
For indie developers, there’s sufficient user demand in this market, but competition is also increasing rapidly. Differentiation comes from going deep on specific scenarios (focus only on interview practice, or only on phone call anxiety) rather than trying to build a general-purpose AI chat product.
Lessons Learned
- Latency is the first engineering problem: Conversation feel is subjective, but response latency over 800ms is perceptible to nearly all users
- Visual realism > feature richness: Users care about “does this feel like a real conversation,” not how long the feature list is
- Validate with the cheap version first: An ElevenLabs + Deepgram + Claude MVP is low-cost and quickly validates whether users actually use it
- System prompt is the core product differentiator: Prompt engineering that makes AI behave naturally in conversation matters more than any infrastructure optimization
References
Answers come from this article only. Click any prompt below or open the chat at the bottom right.
🇺🇸 English
Picture this. You're a tech YouTuber with a big following, and one day a comment lands in your inbox that stops you cold. Someone writes: "I'd love to ask you questions, but I have social anxiety — even typing this feels stressful, let alone getting on a real call." Now, most people would reply with some encouraging words and move on. This person did something different. He decided to build a product.
So today I want to walk you through the engineering behind an AI video-calling app — a place where you can practice real conversation, except the person on the other end of the call isn't a person at all. It's AI. And I want to focus on the decisions an indie developer has to make when they're building something like this with limited time, limited money, and a very hard technical problem at the core.
Let's start with the why. Social anxiety disorder affects roughly seven percent of adults worldwide. At its heart is an outsized fear of being judged, which makes face-to-face conversation — and especially video calls — genuinely stressful. The classic treatment is cognitive behavioral therapy, and specifically something called exposure therapy: you gradually, gently expose someone to the situations that scare them. The theory is solid. But in the real world it hits walls. Therapists are expensive and booked out for months. You can't find a willing human to practice small talk with every single day. And when you do practice with a real person and it goes badly, that failure can actually deepen the anxiety.
So here's the hypothesis behind the product. What if you gave people a low-risk practice space? The conversation partner is AI. If you freeze up, if you fumble, if you say something awkward — you just restart. Nobody's judging you. Nobody even knows.
For that to work, the experience has to clear four bars. First, it has to *look* like a real person is talking to you — not a text box, not a faceless voice. Second, it has to be fast. If the AI takes more than a second to respond, the rhythm of conversation collapses. Third, it has to actually hold a conversation — remember what you said earlier, track context. And fourth, it has to feel safe, which means being honest that it's AI. You never want the user to feel tricked.
Now let's get into the stack, because this is where the trade-offs live.
Start with the video itself. The natural choice is WebRTC, because it's built right into the browser — no app to download — and peer-to-peer connections are fast, under fifty milliseconds in the same region on a good day. But here's the catch for a solo developer: running your own WebRTC signaling and TURN servers is a real chunk of work. So the practical move is a managed service. You've got Daily.co, which is roughly four-tenths of a cent per participant per minute and gets you shipping fastest. There's Livekit, which is open source and self-hostable with a generous free tier. And there's Agora, which is enterprise-grade and rock-solid but comes with more complicated pricing. For a first version, you lean on the managed option and save yourself the infrastructure headache.
Next, the hard one: giving the AI a face. This breaks into three tiers. The simplest is a static image plus audio — a still picture that doesn't even move its mouth, just talks. Dead easy to build, but the experience is flat. The middle tier is a 2D avatar with lip-sync, using something like Ready Player Me, where you map the audio waveform to mouth movements. Cheap, works, but it looks like a virtual streamer, not a human. And then the top tier: real, AI-generated video. Services like Tavus and HeyGen let you upload a video of an actual person, and then generate a live speaking video stream in real time that matches whatever the AI is saying. The latency runs somewhere between three hundred and eight hundred milliseconds, and the result is the closest thing to talking to a real human. Tavus even has a Conversational Video Interface built specifically for this. The smart play for an indie dev? Validate the idea with the cheap tiers first, and only upgrade to real-time video once you've got users who care.
Then there's the pipeline that actually makes a conversation happen. You speak, and the system has to hear you. That's speech recognition — ASR. Whisper from OpenAI is accurate but too slow for live use, over half a second of latency. Deepgram is tuned for real-time streaming and comes in under two hundred milliseconds. So for this kind of product, Deepgram or AssemblyAI is the go-to.
Your words become text, and that text goes to a language model to generate a reply. Here, latency is everything, so you want models that start talking fast — think GPT-4.1, Claude Haiku 3.5, or Gemini Flash. And this is where a huge amount of the product magic lives: the system prompt. That's what tells the AI to *be* a job interviewer, or a stranger you're asking for directions, or someone you're calling on the phone — and to pace itself naturally.
Finally, the model's reply, still just text, has to become a voice. That's text-to-speech. ElevenLabs gives you the best audio quality with real-time streaming. OpenAI's TTS is simple and solid. Play.ai is designed for conversation and can adjust emotional tone.
Now here's the part that keeps engineers up at night. Add up that whole chain — you finish speaking, then two hundred milliseconds for recognition, three hundred for the model to start replying, two hundred for the first chunk of audio. That's around seven hundred milliseconds, best case. And seven hundred is already living on the edge. The moment any single link hiccups — a network wobble, the model under load — you blow past that one-second threshold where it stops feeling natural. This latency budget is genuinely the hardest engineering problem in the whole product.
A couple of supporting pieces make it work. There's voice activity detection — the system needs to know the *exact* moment you've stopped talking. Trigger too early and the AI cuts you off mid-sentence. Trigger too late and you add lag. Silero VAD is a popular open-source tool for this. And there's memory: language model APIs are stateless, they forget everything between calls, so you have to manage the conversation history yourself — keep the last few turns in full, summarize the older ones to save on tokens, and stash the important facts in a vector database.
Quick word on the market, because it tells you something. AI companion apps crossed 220 million downloads in 2025, and the number of those apps grew seven hundred percent in just two years. The company behind the virtual pet Pengu raised a fifteen-million-dollar Series A specifically for social AI companions. So the demand is clearly there — but so is the competition. And the lesson for a small builder is: don't try to build a general-purpose AI chat buddy. Go deep on one specific scenario. Just interview practice. Just phone-call anxiety. That focus is your edge.
So let me leave you with the three things worth remembering.
One: latency is the whole game. Conversation feel is subjective, sure, but push response time past eight hundred milliseconds and almost everyone can feel it. Get that wrong and nothing else matters.
Two: looking real beats being feature-rich. Users don't care how long your feature list is. They care about one thing — does this feel like a real conversation?
And three: build the cheap version first. An MVP stitched together from ElevenLabs, Deepgram, and Claude costs very little and answers the only question that matters early on — will people actually use this? Because in the end, the deepest differentiator here isn't the infrastructure. It's the prompt engineering that makes the AI feel human. That's the part no managed service can hand you.
And that's the real story. A single fan message, a hard latency problem, and a builder who decided the best reply wasn't advice — it was a tool.
🇹🇼 中文
有些產品來自市場調查,這個產品,來自一句「不好意思」。
作者是一位會開直播的技術 YouTuber。他直播的時候常常鼓勵觀眾連麥提問,但幾乎沒人敢。一問原因,都是那句:「不好意思,在那麼多人面前說話。」偏偏出於隱私考量,他又沒加任何粉絲的微信、也沒留電話,一直找不到一個合適的一對一聊天管道。
求人不如求己,他乾脆自己動手做了一個,叫做 o2o,一個完全跑在瀏覽器裡的一對一視訊通話平台。不過所謂「自己做」,其實全程都是 AI 在寫程式碼。他扮演的,是大家最討厭的那種產品經理——備好環境、定好需求,然後翹著腳等驗收。
那 o2o 到底是什麼?很簡單。它不用安裝任何東西,你直接點「發起通話」,把產生的網址發給對方,兩個人就能在瀏覽器裡視訊。它不限時,想聊多久就聊多久。而且全平台通吃,任何電腦、手機的瀏覽器都能開,因為它用的全是原生瀏覽器功能。之後還規劃了螢幕共享、視訊錄製、檔案分享這些功能。
這裡要特別澄清一下:o2o 不是「跟 AI 通話」的產品,AI 只是它的建造者。實際通話的是兩個真人。這也正好回應了那位社恐粉絲的需求——一個私密、低門檻、不用面對一堆觀眾的一對一管道。
接下來是重點:為什麼這東西幾乎零成本?
作者說他「主打的就是一個勤儉節約」。整個專案,是部署在他現有的資源上——雲端上的 Kubernetes 叢集、還有 Redis 跟 Postgres 實例,所以沒有增加任何額外開銷。
有人會問,視訊通話的頻寬難道不用錢嗎?這就要講到技術棧了。核心是兩個原生瀏覽器 API。第一個是 WebRTC,早在 2011 年就成了 W3C 標準的網頁即時通訊 API,能讓兩個瀏覽器做端對端、也就是 P2P 的音視訊傳輸。第二個是 WebSocket,負責在雙方之間同步資訊。
關鍵就在這句話:音視訊流,是端對端直接傳的,伺服器只負責幫兩邊「同步一下資訊」。所以整個後端,只需要一個很基本的業務 API,加上一個 WebSocket 介面。而一次完整的視訊通話,這些介面最多也就消耗幾十 KB 的流量。你可以想像整個流程是這樣:瀏覽器 A 發起通話,把連線資訊丟給後端,後端轉給瀏覽器 B,B 回應,後端再同步回 A——這一來一往都只是幾十 KB。等連線談妥,真正的音視訊流,就在兩個瀏覽器之間直接跑,完全不經過伺服器。
而這裡藏著一個刻意的取捨。作者在給 AI 的 prompt 最後,特別加了一句要求:只提供 STUN Server,不要提供 TURN Server。
這兩個東西差在哪?STUN,是透過公共網路確認雙方的 IP 位址,讓兩端能直接建立 P2P 連線。而 TURN,是當雙方所在的網路——比方某些企業網、校園網——不允許公網端對端連線的時候,就需要它當中轉站,所有視訊流都得從這台伺服器進出。
問題就在這:一旦用了 TURN,所有的頻寬成本,就得作者自己扛。權衡之後他決定,o2o 乾脆不支援企業、校園這種複雜網路,也就不提供 TURN。
這也正是「想聊多久就聊多久」的底氣所在——因為端對端消耗的,是使用者自己的流量,對作者來說無所謂。這是一個很典型的獨立開發者成本決策:用縮小適用範圍,換來近乎為零的營運成本。
不過,真正的成本,其實藏在 debug 裡。
整個開發花了大約 10 小時,但大部分時間其實是 AI 在跑,他只是偶爾測一下、找找 bug。整個任務分成 6 個對話 session,以這個模型 20 萬的上下文窗口來算,總共燒掉了大約 120 萬個 token。
有趣的是這些 token 的分佈。最初的 prompt,加上第一版生成的程式碼,總共只用了大概 10 萬 token。後面上百次對話、上百萬 token,基本上——全都花在 debug 上。
因為 session 之間會失憶,他的作法是:每個新 session 一開頭,就把「從最初的 prompt 到前面所有 session 的總結」全塞進去,尤其詳細記錄上一個 session 發生的所有事——提交了哪些資訊、發現了哪些 bug、最後怎麼修的。等於是手動幫 AI 維護一份長期記憶。
其中最誇張的,是一個吃掉 20 萬 token 的狀態機 bug。
第五個 session,幾乎整整一個小時,都在修同一個問題:視訊通話過程中,斷線重連。
根源是這樣的:WebRTC 原理上其實是允許多人視訊的。你要做到嚴格的一對一,就得在業務邏輯裡限制同時連線人數,還要即時記錄每個人的狀態——進入、通話開始、斷開、通話結束。麻煩的是,這些狀態同時存在三個地方:WebSocket 連線裡、伺服器的記憶體裡、還有 Redis 快取裡。只要狀態一變、同步沒處理好,記憶體跟快取就對不上,於是出現各種詭異症狀:一個人斷線,結果全員被踢下線;或者你斷線重連,系統卻跟你說「已滿員」。
這就印證了那句老話:一切計算機問題,都是狀態機問題。
那一個小時裡,AI 就根據作者這個「QA」的回饋,反覆翻自己寫的程式碼、反覆打補丁——新增中間狀態、修正記憶體跟快取的讀寫順序、及時清理過期的 Redis 資料。最後大概花了 20 萬 token 才把這一個 bug 搞定。但作者的結論是:綜合算下來,這絕對比他自己下場 debug 划算。
從這個專案,作者看到一個趨勢。他說,當「一句話生成一個沒什麼用的小網站」這種 Vibe Coding 時代過去之後,AI 編程如果想真正進入複雜的軟體工程領域,最重要的能力,就是在超長的任務窗口裡持續 debug。
原因很直接:稍微有點複雜度的軟體,都會結合前端、後端、資料端,再加上一堆業務邏輯,AI 幾乎不可能一次到位。所以大部分時間,注定要耗在「測試、debug」的循環裡。o2o 就是最好的例子——10 萬 token 蓋好房子,剩下一百多萬 token,全在修水電。
最後他還列了幾個接下來想加、而且光靠瀏覽器原生 API 就能做的功能:用 RTCDataChannel 做端對端檔案傳輸、用 MediaDevices API 做螢幕共享、用 MediaStream API 做視訊錄製、用 Web Audio API 做聲音降噪、還有用 WebCodecs API 幫畫面打浮水印。他的感想是:「瀏覽器就是一個無窮無盡的寶庫。」對想省成本的獨立開發者來說,這句話真的值得抄下來——很多你以為得付錢給第三方服務才能做的事,瀏覽器早就內建好了。
好,聊到這,幫你收攏三個核心要點。
第一,o2o 的省錢秘訣,是架構上的取捨:只給 STUN、不給 TURN,讓音視訊走端對端直傳、燒的是使用者自己的頻寬,作者這邊近乎零成本,代價是放棄企業跟校園這類複雜網路。
第二,AI 寫程式的真正成本不在「生成」,而在「debug」。120 萬 token 裡,只有 10 萬用在蓋房子,其餘全在修 bug,光一個斷線重連的狀態同步問題就吃掉 20 萬。
第三,AI 編程要進入真實工程,分水嶺是「在超長任務窗口裡持續 debug」的能力。而且別忘了,瀏覽器本身就是一座寶庫,很多功能不必外求。
Tags
Related Articles
RAG's Five Stages: From Pipeline to Reasoning Retrieval, and the Naive RAG on My Own Site
Over the past two years RAG evolved from a 'linear pipeline' to 'loop-based reasoning'. It maps cleanly to five stages: Naive, Advanced, Modular, Graph, Agentic. The real inflection point is control moving from pipeline to agent — a System 1 → System 2 shift. Looking back at engineer-news's own RAG stack, it's stuck at the Naive edge — so this post also lays out what to fix next.
Building a Real RAG: 5 Infra Lessons from InfiniFlow's 2024 Year-in-Review
The previous post zoomed out for a five-stage panorama of RAG. This one zooms in on the five infra lessons any real RAG has to face: document ingestion, contextualized chunking, three-lane hybrid search, tensor reranker, and GraphRAG's semantic gap. Each lesson is checked against engineer-news's current stack, ending with a priority list for a personal site.
J-lens: Anthropic's New Interpretability Tool for Reading Claude's Inner Thoughts via a 'Global Workspace'
Anthropic proposes J-lens, an interpretability tool that captures the 'verbalizable' representations inside a Transformer, and uses it to show that Claude contains a privileged subspace analogous to the neuroscientific 'global workspace' — a small set of vectors that broadcast, drive reasoning, respond to external steering, and even leak signals during deception and evaluation awareness.