Case Study

Voice Brain Dump

Speak your thoughts. Find them later by meaning, not by scrolling through raw transcripts.

The problem

Voice memos solve capture, not recall. A rambling thought becomes a wall of text you have to scroll through to find again — transcription without retrieval is just a slower way to lose an idea.

Speaking is the fastest way to get a thought out of your head, which is exactly why the good ones arrive at useless moments — walking, driving, half-asleep. People capture them because capture is easy. Then the recording joins forty others with names like “Recording 41” and a date, and the thought is gone in a way that feels worse than never having recorded it.

Transcription looks like the fix and isn't. It converts audio you can't skim into text you won't read. Spoken language doesn't transcribe into something searchable — it comes out as unpunctuated drift with false starts, self-corrections, and the actual point buried three tangents in. Keyword search over that fails for a specific reason: you remember what you meant, not the words you happened to say while working it out.

The gap isn't in getting thoughts in. It's that the thing holding them has no way to hand one back when it becomes relevant.

The approach

A pipeline that takes raw speech, transcribes it, and indexes it semantically — so a thought spoken weeks ago becomes searchable by meaning later (“that idea about pricing tiers”) instead of requiring the exact words or a scroll through every transcript. Speaking becomes the entire input step; retrieval works the way memory actually does — by association, not exact match.

That last part is the whole design. Nobody recalls a thought by its wording; they recall the shape of it, roughly when it happened, what it was near. Embedding the transcript rather than indexing its words means a query written months later in completely different language still lands on the right recording — the match is on what was meant, not on which synonym got used on the day.

The capture side stays deliberately dumb. One action, no titles, no tags, no folders, nothing to decide while a thought is still half-formed. Any organisational step at capture time is a step people skip when it matters most, and the entire premise is that speaking should cost nothing.

Speech-to-text·Embeddings·Vector search
>okay so the thing about pricing… the tiers, for the plans, maybe
found six weeks latersearched: “that idea about pricing tiers”

A spoken ramble becomes one findable idea.

How it works

Four stages between speaking and being able to find it again.

01
Capture
One action to start talking, and nothing else asked of the user. No title, no category, no decision about where it belongs — the thought is often not clear enough at that moment to file anyway.
02
Transcribe
Speech to text over real recordings: background noise, trailing sentences, and the mid-thought corrections people make constantly when talking something through out loud.
03
Index
The transcript is embedded and stored with its timing, so retrieval matches on meaning while the original audio stays available underneath the text.
04
Retrieve
A question in ordinary language is matched against the index, returning the recording that carries that idea — with the passage that matched, rather than the whole transcript to re-read.

What made it hard

Spoken thought is messier input than anything a retrieval system usually gets handed.

Speech isn't prose

People restart sentences, contradict themselves halfway through, and arrive at the point after abandoning two others. Embed that verbatim and the vector reflects the meandering as much as the idea — so the transcript has to be treated as something to interpret, not just store.

One recording, several ideas

A two-minute ramble is rarely about one thing. Treated as a single unit, its embedding averages three unrelated thoughts into a vector that matches none of them well. Where to split a monologue is the same segmentation problem the video work runs into, without visual cues to help.

Recall is vaguer than search

Queries arrive as half-memories — a fragment, a rough timeframe, a feeling about what it was near. That's a lower-signal query than a search box normally receives, and the ranking has to stay useful when the person asking can only approximately describe what they want.

What this proves

The same retrieval pattern behind the Video Search and Memory work, applied to spoken, unstructured input.

01
Unstructured input, structured retrieval
Turning messy, rambling speech into something queryable — not just transcribed.
02
Full pipeline ownership
Speech-to-text and semantic search working together end-to-end — not just a wrapper on an existing transcription API.
03
Capture that survives contact with real habits
Designed around when people actually record — mid-walk, half-formed, one-handed — rather than around an idealised user who files things properly.
04
Applicable beyond personal use
The same pattern extends to meeting notes, voice-logged customer feedback, or any workflow where people talk faster than they type.

Where it sits in the rest of our work

This is the smallest complete version of a problem that keeps recurring: something valuable gets said, and there's no path back to it later. The Video Search work is the same shape at library scale, and the Internal Tool Memory exploration is the same shape across a team rather than one person.

Building it small was the point. A single user and a few hundred recordings surface the parts that are genuinely hard — segmentation, vague queries, ranking that holds up when the asker is unsure — with none of the infrastructure a larger deployment would otherwise hide them behind.

Status — live

Built and working — speech-to-text combined with semantic retrieval end-to-end, the same underlying pattern behind the Video Search Engine and Internal Tool Memory work, applied to voice input.

We have worked with the People across the globe

EUROPE
USA
JAPAN
INDIA
PHILIPPINES
Let's Talk