This one started with a tool that already worked: transcribe.py, a personal script running OpenAI Whisper against video files, wrapped in a macOS Automator droplet with alert dialogs standing in for a UI. The engine was never the gap — the interface was, and there was no way to see progress, fix a mistranscription, or run it anywhere but this one Mac. Rebuilding it meant a local FastAPI web app instead of the droplet, and a swap from OpenAI’s Whisper to faster-whisper — a deliberate middle ground once it became clear all three Whisper variants are equally private (nothing ever leaves the machine); the real trade-off was dependency footprint and auditability against packaging effort, not data handling.

Getting the rebuild running was the easy part. Making it launchable the way an actual user would use it — double-click an icon, get a browser tab — surfaced three real bugs, and every single one of them was invisible from a terminal and only showed up on a genuine Finder double-click: an architecture mismatch (Finder/LaunchServices translating an Apple Silicon process through Rosetta, crashing arm64-only compiled dependencies that loaded fine from a shell), a code-signing requirement this version of macOS enforces even independent of the quarantine flag, and a PATH that excludes Homebrew’s ffmpeg for any GUI-launched process. Each one took real evidence to track down — launch logs, codesign/spctl output, process checks — rather than a guess that happened to be right.

Main takeaways

  • The engine was never the missing piece in the original tool — the interface was. A good pipeline with no way to see progress or fix a mistake isn’t a finished tool.
  • None of the three Whisper engine options (openai-whisper, faster-whisper, whisper.cpp) differ on privacy — all three run fully offline. The real choice is dependency footprint and auditability versus packaging effort.
  • “It works when I test it from a terminal” and “it works the way the real user will launch it” are different claims for anything meant to be double-clicked — three separate bugs proved that in one session, not one.

What I got wrong

  • Every terminal-based test gave false confidence — the architecture crash, the code-signing rejection, and the missing ffmpeg path were each invisible until tested through an actual Finder double-click.
  • Don’t yet know whether the same gaps exist on hardware not yet tested against: an Intel Mac, or a completely clean clone with none of this session’s incremental fixes already in place.