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 might leave your machine is the cleanup pass — and even that is your choice, routed to your own Pippa or a local model, never a stranger's server.

A Surface, Not a Brain

Firekeeper is a client surface for Pippa, not a second Pippa. When it wants a smart cleanup, it asks cwkPippa; 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 be small 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 a byte can optionally leave the machine -- and that's a
# per-request choice, never a default.

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