# Build brief — a focused alternative to ekto > **Verdict:** Partly, if you narrow it · **Buildability:** 44/100 · **Category:** Voice AI > **Source:** https://www.canitbevibecoded.com/ekto > Independent editorial assessment from Can It Be Vibe Coded? Not affiliated with, endorsed by, or derived from ekto. Verify current pricing and capabilities before acting. ## Context **ekto** — Real-time voice translation: speak in one language, get the other side rendered back in near real time. It currently costs $29.99/mo. The pipeline is no longer exotic: capture mic audio, segment it with a voice activity detector, transcribe with Whisper, translate, speak it back with a local TTS voice. An agent can wire that into a working local app in a focused implementation and it will genuinely translate a conversation. What it will not do out of the gate is stay graceful for an hour: chunk boundaries clip words, speaker turns bleed together, latency creeps as the buffer grows, and the sentence by sentence pacing that makes these apps usable in real conversation is a tuning problem, not a coding problem. You also get no phone app, which is where voice translation actually happens. Fine for a desk setup and travel prep, unconvincing when you are holding it out to a stranger in a market. This brief describes a focused, single-operator replacement for the part of ekto that is genuinely reproducible. It is deliberately narrower than the product it replaces, and it says so in writing. Build the useful core; do not pretend to have rebuilt the rest. ## What you are building Streams mic audio over a WebSocket to a local Whisper plus translation plus TTS chain and plays the translated speech back with running transcript. - Turn supplied scripts into speech or avatars through documented model APIs. - A responsive interface with real empty, loading, success, and error states. ## Requirements ### Functional - Python 3.11 and a machine with at least 8GB RAM, GPU strongly preferred. - Local model downloads: faster-whisper and a Piper voice per target language. - Headphones, otherwise the TTS output feeds back into the mic. ### Data and integrations - A browser with mic permission, or an API key if you swap in a hosted translation model. Each of these needs a real account, credential, or quota. Set them up before writing feature code. ### Non-functional - Accessibility: semantic markup, labelled controls, visible focus, and reduced-motion support. - Security: server-side secrets, validated input, and no credentials in the client bundle. - Reliability: retries with backoff on external calls, and a clear failure state when a provider is down. - Portability: the operator can export their data and leave without losing it. ## Implementation brief Build a local real-time voice translation app. No accounts, no cloud services, no telemetry. Stack, non-negotiable: - Python 3.11 + FastAPI, served with uvicorn on port 8000. - One HTML page with vanilla JS, no framework, no build step. - Audio in: browser getUserMedia, 16kHz mono, streamed to the server over a WebSocket in 250ms PCM chunks. - Speech to text: faster-whisper (small model default, configurable via .env). - Segmentation: silero-vad or webrtcvad to detect end of utterance. Do not translate on fixed timers, translate on detected utterance boundaries. - Translation: argostranslate with locally installed language pairs. - Text to speech: piper, one voice per target language, downloaded on first run into ./models. Behavior: - User picks source and target language in a dropdown before starting. - Press Start, speak, and on each detected utterance the server returns: original text, translated text, and a WAV of the translated speech. The page appends both lines to a running transcript and plays the audio. - Show live latency per utterance in ms in the corner. Be honest, measure end of speech to audio ready. - Handle overlap: if a new utterance arrives while audio is playing, queue it, never drop it. - Long session hygiene: cap the in-memory transcript at 500 lines, reset the whisper buffer after every utterance, log RSS every 60 seconds. Out of scope, do not build: mobile app, user accounts, cloud sync, speaker diarization, a two-phone conversation mode. Deliverables: main.py, static/index.html, static/app.js, requirements.txt, .env.example (WHISPER_MODEL, DEVICE, COMPUTE_TYPE), scripts/download_models.py, and a README with exact run steps plus one paragraph on where this degrades in sessions over 20 minutes. Run it, speak a test sentence in English with Spanish as target, and paste the measured latency into the README. ## Delivery standard - Inspect the repository first, then write a short implementation plan before writing code. - Deliver the smallest complete end-to-end workflow first; every primary control must work against persisted data. - Use real validation and storage; never substitute fake dashboards, decorative controls, hard-coded success states, or mock integrations. - Include responsive layouts plus genuine empty, loading, success, validation, and failure states. - Keep secrets server-side in environment variables, provide .env.example, and never commit credentials or user data. - Add structured logs around every external call and return actionable errors without leaking sensitive details. - Write unit tests for the core logic and one automated test of the main user journey. - Finish with a README covering setup, architecture, data location, backups, tests, deployment, and known limitations. ## Acceptance criteria - [ ] A clean install starts the app using only the README and .env.example. - [ ] The primary journey works from first visit through saved result, reload, edit, export, and deletion where applicable. - [ ] Invalid input, missing configuration, provider failure, and an empty database each have a usable state. - [ ] The interface works at 390px and 1440px, is keyboard navigable, and shows visible focus on every control. - [ ] Tests, type checking, linting, and a production build all pass with no ignored failures. - [ ] No part of the interface implies a live integration, security guarantee, or scale capability that was not actually built and verified. ## Non-goals Do not build these, and do not claim to have replaced them: - Long session reliability: memory growth, drifting segmentation and dropped turns after the first 20 minutes. - Clean sentence by sentence pacing and turn detection, which is most of the perceived quality. - A mobile app, so no translating anything while standing up. - Offline or low-bandwidth behavior tuned for actual travel. - Latency budgets someone else already fought for: streaming partial results instead of waiting for a full segment. ## What you still own after launch - Secure credentials, rotate secrets, and handle provider rate limits. - Run migrations, backups, restores, and dependency updates. - Test the critical journey after every model, API, or hosting change. - Monitor failures and fix the edge cases a first prompt will miss. ## Risk **Operational risk.** The code is achievable; dependable data, integrations, and ongoing operations are the real cost. Editorial confidence in this assessment: low. No reviewed project implementation is linked yet. --- Generated by [Can It Be Vibe Coded?](https://www.canitbevibecoded.com) · Full report: https://www.canitbevibecoded.com/ekto