# Build brief — a focused alternative to Hedy > **Verdict:** Partly, if you narrow it · **Buildability:** 63/100 · **Category:** Meeting Notes > **Source:** https://www.canitbevibecoded.com/hedy > Independent editorial assessment from Can It Be Vibe Coded? Not affiliated with, endorsed by, or derived from Hedy. Verify current pricing and capabilities before acting. ## Context **Hedy** — Listens to your meetings, classes and calls live and feeds you suggested questions, context and notes while they are still happening. It currently costs $12.99/mo. The pieces are all commodity now: capture audio, stream it through a local Whisper variant, keep a rolling transcript, and every few seconds ask a model for the next good question. An agent will get you that in a focused implementation on a laptop, and the transcript-plus-summary half will genuinely be fine. What it will not get you is a phone in your pocket that survives being backgrounded during a two hour lecture, or sub-second suggestions that arrive before the moment passes. Live assistance is a latency and UX problem more than an AI problem, and that is exactly the part that takes weeks of fiddling. Build it if you mostly sit at a desk; keep paying if you mostly do not. This brief describes a focused, single-operator replacement for the part of Hedy 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 A local desktop app that records mic and system audio, streams a rolling transcript, and every few seconds asks a model for suggested questions and notes in a side panel. - Capture supplied audio, transcribe it, create structured notes, and export them. - A responsive interface with real empty, loading, success, and error states. ## Requirements ### Functional - Consent from whoever you are recording, which is on you. ### Data and integrations - A laptop with a decent CPU or GPU for local Whisper, or an API key for hosted transcription. - An LLM API key in .env. - A virtual audio device (BlackHole on macOS, WASAPI loopback on Windows) to capture the other side of the call. 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 desktop meeting copilot. Stack: Python 3.11, FastAPI backend, a single HTML page with vanilla JS and a WebSocket, no build step. Run everything on localhost, no accounts, no telemetry, no cloud storage. Audio capture: use sounddevice to record from a selectable input device at 16kHz mono. Document in the README that capturing the other side of a call requires a loopback device (BlackHole on macOS, a WASAPI loopback device on Windows) and let the user pick it from a dropdown of available inputs. Optionally mix two devices (mic plus loopback) into one stream. Transcription: faster-whisper with the small.en model by default, configurable via .env. Process audio in 5 second chunks with a 1 second overlap, maintain a rolling transcript in memory, and push each new segment to the browser over the WebSocket with a timestamp. Assistance loop: every 15 seconds, or on a manual "nudge" button, send the last 2000 characters of transcript plus a short session brief the user typed at the start to an LLM via the OpenAI-compatible API. Key comes from OPENAI_API_KEY in .env. Ask for exactly three things in JSON: two suggested questions to ask next, one factual note or definition worth knowing, and one line of what seems to be at stake. Render these as cards in a right-hand panel, newest on top, with the old ones dimmed rather than deleted. Session end: on stop, write the full transcript and all generated cards to ./sessions/YYYY-MM-DD-HHMM.md, then make one final call for a summary with action items appended at the top of that file. UI: two columns. Left is the live transcript, auto-scrolling, with a pause button. Right is the assistance cards. A header with device picker, session brief field, start/stop, and a visible recording indicator. Dark, dense, no animations. In scope: local recording, streaming transcript, periodic suggestions, markdown export, session list page that greps past files. Out of scope: mobile, speaker diarization, calendar or Zoom integration, multi-user, auth, hosted anything. Do not add them. Ship a README with the loopback setup steps, the exact pip install line, a .env.example, and a blunt note that recording other people may require their consent where the user lives. ## 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: - Mobile apps that keep recording reliably when the screen is off, which is where most of these sessions actually happen. - Tuned latency: your DIY suggestions arrive a beat late, and a beat late is useless in conversation. - Speaker diarization and meeting-type presets that shape the assistant for a sales call vs a lecture vs a doctor visit. - Calendar and conferencing integrations that join and label sessions for you. - Hosted, searchable history across every session with no laptop babysitting. ## 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. - Maintain every third-party integration as APIs and OAuth rules change. ## 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/hedy