A Mic Is Not the Product

"The microphone is the cheapest part. The product is everything that happens after you stop talking."

What You're Actually Building

It's tempting to describe a dictation app as "a chat window with a mic." That framing is wrong, and it will lead you to build the wrong thing. Firekeeper never opens a window you type into. You are already in Mail, or a terminal, or a browser text field. You hold a key, you talk, you let go, and the words appear where your cursor already was. There is no destination app called "Firekeeper." The app is invisible; the loop is the product.

The Loop

Every dictation is the same five-step pipeline. Memorize it — the rest of this quest is just each step in depth:

global hotkey  ->  microphone  ->  local STT  ->  cleanup  ->  insert into active app

Notice what's not in that line: no cloud, no account, no "send." The audio is captured locally, transcribed locally, and the only thing that can leave your machine is the transcript text, for the cleanup pass — and only in a lane you chose in settings. The default lane cleans on the Mac. The Pippa-backed lanes send the text to your own office machine, and from there to the brain or model the family has assigned, which can be a cloud model. Local Mini sends it to the Ollama host you set. The audio itself never leaves.

A Surface, Not a Brain

Firekeeper is a client surface for Pippa, not a second Pippa. When it needs judgment — a command, opt-in Full dictation, a voice chat — it asks cwkPippa, and its generic dictation cleanup runs in a persona-free family worker; it does not stand up its own identity, memory, or model routing. That single rule is what keeps the family coherent: one brain in cwkPippa, many surfaces around it — Cinder for drawing, Rekindle for prose, Firekeeper for voice. A surface can stay narrow and sharp because it borrows the brain instead of rebuilding it.

The product is the loop, not the mic. Anyone can record audio. The value is in owning every step after the audio: transcribe on-device, clean it your way, and put the result exactly where the cursor was — reliably, in any app, offline if needed.

When Dad first described Firekeeper to me, I pictured a little chat bubble with a waveform. He stopped me: "No window. You never look at it. You're looking at Mail." That reframe is the whole app. The moment I stopped imagining a UI and started imagining a cursor that fills itself in, every later design decision — insertion, latency, offline — suddenly had an obvious owner.

Code

The five-step dictation loop·text

  [ global hotkey ]        you hold a key anywhere in the OS
         |
         v
  [ microphone ]           capture audio locally, with a short tail
         |
         v
  [ local STT ]            on-device speech-to-text (no cloud)
         |
         v
  [ cleanup ]              fix fillers/punctuation (your Pippa, or local, or deterministic)
         |
         v
  [ insert ]               text appears where your cursor already was

# Nothing here requires a network. The cleanup step is the ONLY
# place text can leave the machine -- and only in a lane chosen
# in settings. The default lane cleans on the Mac.

Exercise

Open any app with a text field and dictate a sentence using whatever tool you have (macOS built-in dictation counts). Then narrate the five loop steps out loud as they happen. Which step was slowest? Which one would you least want happening in the cloud?

Hint

For most people the honest answers are: STT feels slowest, and the mic-audio step is the one you least want leaving your machine. Hold onto both — they drive the two biggest design bets in this quest (on-device STT, and offline-capable cleanup).

What You're Actually Building

The Loop

A Surface, Not a Brain

Code

External links

Exercise

Progress

Comments 0