Reverse-Spec, Not Reverse-Engineer

"You're not stealing the engine. You're watching how the car drives and building your own that drives the same way."

The Only Thing You Can See

Wispr Flow is closed-source. You cannot read its code, and you should not try to. What you can see is everything that matters for a clone: its public docs, its support pages, and its observable behavior when you use it. Push a hotkey — audio starts. Release — text appears. Speak a filler word — it vanishes in the output. Say "actually, make that Tuesday" — the correction is applied, not appended. None of that requires reading source. It's all observable, and observable behavior is a spec you're free to reproduce.

Reverse-Spec vs Reverse-Engineer

These are different acts with different ethics. Reverse-engineering pulls apart the implementation — decompiling binaries, extracting algorithms, copying the backend. Reverse-spec writes down the observable interaction model — the hotkeys, the insertion behavior, the cleanup feel — and rebuilds it independently. The first copies how they did it; the second copies what the user experiences. Firekeeper does only the second, and only from public sources.

Reverse-ENGINEER (avoid)      Reverse-SPEC (do this)
---------------------         ----------------------
decompile the binary          read the public docs
copy internal algorithms      note the observable behavior
replicate the backend         rebuild the interaction on your stack
lift prompts / branding       write your own prompts, your own name

What Stays Yours

Because you rebuild from behavior, everything underneath is genuinely yours: your STT engine, your cleanup prompts, your insertion code, your name. That's not a legal fig leaf — it's why the clone is better for your purpose. Wispr transcribes in the cloud; your rebuild transcribes on-device. You couldn't have inherited that by copying their backend even if you wanted to, because their backend is the thing you're deliberately rejecting.

Clone the experience, build the implementation. The reusable, ethical, and useful thing about a closed product is its interaction model — what it feels like to use. Reproduce that from public behavior, and build the guts your own way. You end up with the good UX and none of the parts you didn't want.

The first research pass on Wispr was just me and Dad using it and narrating: "okay, it started recording on key-down... it kept the last transcript... it stripped 'um'..." We were writing a spec by watching, like describing a magic trick from the audience. Every line of that narration became a Firekeeper feature — and not one of them needed their code.

Code

A reverse-spec is a list of observed behaviors·text

# Observed from public docs + using the product:

hotkey down            -> recording starts immediately
hotkey up              -> transcribe, clean, insert
"um" / "uh"             -> removed from output
"actually, X"           -> treated as a correction (replace, not append)
no editable field      -> copy to clipboard + notify
"...press enter"        -> strip phrase, synthesize Enter after insert

# This list is a SPEC. Nothing here is their source code.
# Rebuild each line independently and you have the loop.

Exercise

Pick a closed product you admire and write a five-line reverse-spec of one feature: only observable behaviors, no guesses about implementation. Then mark which lines you could rebuild differently (and better) on your own stack.

Hint

Good reverse-spec lines start with a user action and end with an observable result: 'press X -> Y happens.' If a line describes an internal mechanism ('it uses a transformer to...'), you've slipped from spec into speculation — cut it.

Reverse-Spec, Not Reverse-Engineer

The Only Thing You Can See

Reverse-Spec vs Reverse-Engineer

What Stays Yours

Code

External links

Exercise

Progress

Comments 0