Should I vibe code
Meeting transcription, summaries, and AI chat over conversations
Recording a call is a moment. Indexing two years of them is a discovery request waiting for its letter.
?
Their verdict, the Pro price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Every other notetaker on this site argues about the moment of recording, and that argument is settled: you need permission, and a bot in the participant list is not it. Otter earns a separate entry because what it sells is not the transcript, it is the corpus — two years of conversations, full-text searchable, with speaker labels that persist from one meeting to the next and a chat box on top that will answer "what has Dana said about the reorg". A recording is a moment. A corpus is a permanent, indexed, retrievable record of everything said near you, kept by a system with no retention policy because nobody wrote one. That is not a notes app; it is the first thing a preservation letter asks for, the thing an HR investigation goes looking through, and — because persistent speaker identity means storing a voice embedding — a pile of biometric identifiers sitting in the same database as your dinner plans. The pipeline is a weekend and gets easier every month. The retention schedule, the consent record and the delete-means-delete path are the entire product, and they are the parts an agent will not write unless you make it.
What actually breaks
not "if". the specific failures.
- Retention, because there is none: the archive grows for years and the oldest thing in it is the most damaging
- Speaker profiles, which are voice embeddings — biometric identifiers under several regimes, stored beside the transcripts they identify
- Search, working exactly as designed, in the hands of someone looking for what a colleague said about them
- Deletion that unlinks a transcript from the UI and leaves the audio in the bucket, the text in the search index and the summary in the vector store
- The summary asserting a decision, an owner and a deadline that nobody in the meeting actually agreed
- Auto-join from the calendar, which will eventually record a one-to-one that was not yours to record
- The share link to a transcript, forwarded once, now readable by someone who was never in the room
- Cross-meeting identity, which quietly builds a profile of a person from conversations they had in three different companies
The email arrives on a Tuesday and is very polite. Opposing counsel in a contract dispute has sent a preservation notice, and your company's lawyer wants to know what systems hold records of communications with the other party. Somebody mentions your transcription tool. You had built it for yourself — record, transcribe, summarise, search — and then three colleagues asked for logins, and that was fourteen months ago. What you are now explaining, in a meeting you are not senior enough to be in, is that the system holds verbatim text of roughly four hundred conversations, that it never deleted anything, that it has no per-record retention or legal-hold mechanism, and that the search box will happily return every mention of the counterparty's name in ranked order. Then somebody asks whether the recordings include calls where people outside the company were present, and whether those people were told. You know the answer to the first question. Nobody in the room likes the second one, least of all you, because the consent record that would settle it was a checkbox in the UI that wrote nothing to the database.
Is that you?
the verdict is a default, not a law
- It runs locally, on recordings of your own voice, and the audio never leaves the machine
- Retention is finite and enforced by a job that actually runs — transcripts expire, and you tested that they do
- Every participant was asked in advance, and the asking is recorded next to the transcript rather than remembered
- There is no cross-meeting speaker identity: speakers are Speaker 1 and Speaker 2 within a single recording and nowhere else
- Colleagues have logins, because a searchable archive of what people said becomes an HR instrument the moment two people fall out
- It joins calls from your calendar automatically, which means it will record the meeting you would never have chosen to record
- You are storing voice embeddings to recognise the same person across meetings, which is biometric processing with its own body of law
- Anyone on the calls is in a jurisdiction requiring all-party consent and your consent record is "they saw the bot"
- There is no answer to "delete everything about me" that touches the audio, the transcript, the search index and the embeddings in one action
- The summaries are treated as minutes and nobody re-reads the transcript
If you build it anyway
the checklist, then the prompt that enforces it
- Write the retention policy before the recorder. A number of days, per recording, enforced by a job that deletes audio, transcript, index entries and embeddings together — and a test that proves it did.
- Make consent a record, not a courtesy. Store who was asked, when and how, in the same row as the transcript, and refuse to start a recording without it.
- Default to no persistent speaker identity. Diarisation within a recording is fine; a voiceprint that follows a person across meetings is a different category of data and should require a deliberate opt-in from that person.
- Build the delete path before the search path, and make it a single operation that fans out to every store. Anything else is a deletion feature that does not delete.
- Never auto-join from a calendar. Recording starts because a human pressed a button in that meeting.
- Keep the transcript authoritative and the summary clearly derived, with every claim in the summary linked to the timestamp it came from. Summaries invent decisions.
- Scope search to the recordings a user was actually present for. A cross-corpus search box available to the whole team is a surveillance tool with a nice font.
- Encrypt audio at rest, keep share links expiring and revocable, and log every read of a transcript — reads are the thing you will be asked about.
I am building a meeting recorder that transcribes, summarises and — the part
that matters — keeps everything in a searchable archive. Treat the archive as
the dangerous component, not the transcription, and push back when I ask for
something that makes it permanent.
1. Before any capture code, implement retention: a per-recording expiry
defaulting to 30 days, a job that enforces it, and a test proving audio,
transcript, search index and embeddings disappear together.
2. Then deletion. One operation, by recording or by person, fanning out to every
store. Keep the list of stores it touches in the README.
3. Then consent. Recording cannot start without a stored record of who was
asked, when and how. A UI-only checkbox is not a consent record; refuse it.
4. No calendar auto-join. Recording begins with a deliberate human action in the
meeting it applies to.
5. Diarisation is per-recording only. Do not persist speaker embeddings across
sessions. If I ask you to recognise the same person in every meeting, tell me
that is a voiceprint, that it is biometric data in several jurisdictions, and
make me add a per-person opt-in.
6. Search is scoped to recordings the searcher attended. Never a team-wide search
box over everyone's conversations by default.
7. Summaries are derived and labelled. Every asserted decision, owner or deadline
links to the transcript timestamp it came from.
8. Surface transcription confidence: low-confidence spans render visibly
uncertain rather than as fluent invented sentences.
9. Encrypt audio at rest, keep it out of any backup you cannot expire, log every
read of a transcript, and make share links expiring and revocable.
10. Out of scope: CRM sync and auto-emailing transcripts to attendees — anything
that pushes what somebody said into a system they cannot see.
11. Finish by telling me what Otter costs per seat, and that its retention and
deletion controls are what I am reimplementing, not the transcript.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
Whenever anyone but you is on the call. $16.99 a seat buys a retention setting, an enterprise deletion path, a consent posture argued over by lawyers, and a company that is the named data controller rather than you personally. That last one is the real purchase. The build is genuinely fun and getting easier; the part you cannot buy back afterwards is the archive you accumulated before you thought about how long to keep it.
$16.99/mo is cheaper than your weekend.
The exit that matters here is not migrating to another tool, it is being able to wind the thing down without leaving a liability behind. Keep transcripts as one plain file per recording — timestamped text plus a small JSON sidecar of participants, consent and expiry — in a directory a human can read without your code, and keep the derived layers (search index, embeddings, summaries) rebuildable from those files. Then shutting down is two commands: run the expiry job with a retention of zero on everything past its date, and hand over the folder. Test the second half now, because the day you need it will be a day when somebody is asking you what still exists.
Open-source transcription alignment and diarization tooling useful for DIY Otter-like workflows.
The speaker diarisation toolkit most of these pipelines sit on, and the place the voice embeddings this entry warns about actually come from.
Questions
There are already four transcription entries. Why is this one different?
The others are about the recording: whether you may make it, and who is in the room when you do. Take all of that as read here. This entry is about what happens afterwards — that Otter's product is a permanent searchable index with persistent speaker identity, and that the dangerous artefact is the corpus rather than any single call. You can get the consent question completely right and still build something you would rather not have to describe to a lawyer.
Is a voiceprint really biometric data?
If it is stored for the purpose of identifying a specific person, yes — that is exactly the category the GDPR treats as special under Article 9, and several US states have their own statutes with private rights of action. Diarising "speaker 1 and speaker 2" inside one file is not that. Persisting an embedding so the system recognises the same voice in next month's meeting is, and it is the feature that makes the archive feel magic, which is why it gets built without anyone naming it.
What is the smallest safe version of this?
Local Whisper over a recording of yourself, on your own machine, with a 30-day expiry and no cross-meeting identity. That is a genuinely useful tool, takes an afternoon, and has almost none of the exposure on this page. Everything that turns it into Otter — other people's voices, a shared login, permanent history, a search box over all of it — adds risk in roughly that order.
The summaries are the useful part. Are they safe?
They are the part most likely to be wrong in a way that matters. A summariser will confidently assign an owner and a deadline to a decision the meeting never actually made, and because the summary is what people read, the invented version becomes the record. Link every line of the summary to its timestamp and keep the transcript one click away, or accept that you have built a machine that writes plausible minutes.
- RCFP — Reporter's Recording Guide (US, per-state consent rules)
- GDPR Art. 6 — lawfulness of processing (EU)
- GDPR Art. 9 — processing of special categories of personal data, including biometric data used to identify a person (EU)
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
A bot in the participant list is not consent. It is an announcement, and only where an announcement is enough.
Recording the call is the easy half. Being allowed to is the half nobody prototypes.
You are not building a transcriber. You are building a fleet of headless browsers that must be in the room at 10:00.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice