Case Study Personal Product · BetaCraft · 2025-2026
A macOS app that converts voice into structured AI prompts. Built by me, for me, because the thing I needed did not exist. What happens when there is no client brief, no scope negotiation, and every bad product decision ships directly into your own daily workflow.
01 / The problem
The part of working with AI that nobody writes about is the repetition. Not the quality of outputs - that gets better every month. The repetition of setting up context. Every session, every prompt, the same setup: who you are, what you are building, what kind of output you need, what format it should take. If you use AI heavily across different types of work - writing, code, design briefs, email - you spend a surprising amount of time just getting the model oriented before you get anything useful back.
I built Promptly because I wanted to speak naturally and get a structured, context-aware prompt out the other end - ready to paste into Claude, ready to use, without the setup tax. Not transcription. Not a general AI assistant. Something in between: voice input, structured prompt output, calibrated to the type of work I was actually doing in that moment.
The existing options
Willow, Wispr Flow, Voicy - type with your voice, anywhere. No prompt engineering, no structure. Fast transcription but no AI layer.
The existing options
Superwhisper, Aqua Voice - understand your active app and context. Powerful but solve a different problem: output goes directly into the app, not into a reusable prompt.
The gap Promptly fills
Voice-to-structured-prompt. You speak naturally. Promptly transforms that into a well-formed, context-calibrated prompt you can use anywhere - Claude, ChatGPT, Gemini, a system prompt, a brief. The output is not text. It is a prompt.
02 / What I built
The core interaction is simple: press the trigger, speak, get a structured prompt. The sophistication is in the mode system - eight specialist modes that calibrate the output to the type of work, so the prompt you get for a code task looks fundamentally different from the one you get for an email or an image generation brief.
03 / The PM without a client
Building a product for yourself is a different discipline from managing a client project - and a more honest one. In client work, a bad scope decision can be traced back to a brief, a call, a misunderstood requirement. When you are the PM and the user, every bad decision lands in your own workflow. There is no brief to blame. No client to negotiate scope with. No sprint review where you can say "the requirements changed."
That accountability changes how you make product decisions. On Promptly, I caught myself trying to scope features I thought users would want rather than features I actually needed. The mode selector helper text, for example - I specced it three times before shipping something that actually reduced friction instead of adding it. The prompt eval scorecard came from a genuine frustration with not being able to tell whether Promptly was improving my prompts or just reformatting them. Both features exist because I felt the problem, not because I assumed it.
The PM discipline this forces
When the PM is also the user, feature decisions cannot be deferred to "let us validate with users later." You are the user. The validation is immediate and personal. Every shipped feature either reduces your daily friction or it does not - and you know within 48 hours which one it is.
This also changed how I ran the build. I used the vibe-* framework on Promptly exactly as I use it on client projects - brainstorm, architect, spec, build, review gate before merge. The discipline was the same even though the stakes felt different. The vibe-review gate before every merge caught three regressions during the v2 iteration cycle that I would have shipped if I had been moving fast without the structure. The process works because it is not person-dependent - it is system-dependent.
04 / Iteration history
Promptly has gone through multiple release cycles since the initial build. The version history is a record of real usage friction - each change exists because something was not working in daily use, not because it was on a roadmap.
| Version | What changed and why |
|---|---|
| v1.0 | Initial build. Basic voice capture, single prompt mode, Claude API integration. Proved the core loop worked. |
| v1.x | Mode system introduced. Feature Eight specialist modes replacing the single general-purpose mode. Carousel UI on the landing page. |
| v2.0 | image-builder-v2 Feature — 48 presets, category tabs, variations panel. video-builder-v2 Feature — multi-model support: Veo 3.1, Sora, Runway Gen-4, Kling 2.0, Pika 2.2. Major landing page redesign: 50/50 split hero, bento grid Specialist Modes section. |
| v2.1 | Prompt eval scorecard Feature — before/after comparison between raw transcript and Promptly-generated prompt, so users can see what the AI layer is actually doing. Multi-language transcription support added. |
| v2.3 | Mode selector helper text Design — third iteration before something that reduced friction rather than added it shipped. nvm PATH inheritance fix Fix in Electron child processes - P0 bug causing transcription to fail on launch for users with nvm-managed Node installations. |
| v2.4.1 | Settings gear button Fix — was not rendering in certain viewport sizes. ffmpeg path configuration Fix — now user-configurable rather than hardcoded. Splash screen manual override Fix for the not-responding state. Current shipping version as unsigned DMG. |
05 / What building this taught me
Client projects have a natural buffer between the PM and the consequence of product decisions. Sprints absorb bad calls. Scope negotiations create flexibility. The client relationship creates a feedback loop that is, by design, somewhat forgiving. Building a product you use yourself removes that buffer entirely.
Lesson from client work
In client delivery, scope can always be revisited, deferred, or reframed. The SOW is a contract, but it is also a living document.
Lesson from Promptly
When you use the product every day, a deferred feature is a daily friction point. There is no reframing - it either works or it does not, every time you open the app.
Lesson from client work
Feature decisions are validated through stakeholder sign-off, user testing, or sprint review feedback.
Lesson from Promptly
You know within 48 hours whether a feature reduced friction or added it. The feedback loop is honest in a way that client feedback rarely is.
The eval scorecard feature is the clearest example of this. I had been using Promptly for weeks and could not answer a basic question: was it actually improving my prompts, or was it just making them longer? I needed evidence, not intuition. The scorecard came from that genuine frustration - a before/after comparison that shows what the AI transformation layer is actually doing to the raw transcript. That feature would never have appeared in a client brief because no client would have thought to ask for it. It exists because I was both the PM and the user and I needed to know.
The transfer back to client work
Building Promptly made me a better client-facing PM. The habit of asking "does this feature reduce friction or add it - and how quickly will I know?" is now in every sprint review I run. The answer is always faster and more honest than a stakeholder sign-off.
06 / Where it is now
Full feature set live: 8 modes, image-builder-v2, video-builder-v2, eval scorecard, multi-language transcription. Signed builds blocked by a codesign issue on the uninstall script - in progress.
50/50 split hero with live mode carousel, bento grid specialist modes section, animated waveforms per mode. Self-hosted on GitHub Pages.
The same skill chain used on client projects - brainstorm, architect, spec, review gate before merge - caught three regressions during the v2 cycle. The process is system-dependent, not person-dependent. It works on Promptly exactly as it works on Brieflex.
Detect the frontmost macOS app on trigger and auto-switch mode: VS Code to Code, Mail to Email, Figma to Design. Zero manual mode switching. Uses NSWorkspace.shared.frontmostApplication via Electron shell.
Apple notarisation pending resolution of the codesign issue on uninstall.sh. Required before any wider distribution.
07 / Reflection
Most PM portfolios show client delivery - projects where the brief came from someone else, the team was assigned, and success was measured against an external definition. That is the core of the job and it should be in the portfolio.
But Promptly shows something those projects cannot: what happens when the PM makes every product decision without a net. No brief to interpret. No client to validate with. No sprint review to surface problems. Just the product, the daily usage, and the honest feedback loop of using something you built every day.
The discipline that produces is not different from client PM work - it is the same vibe-* framework, the same spec-before-build, the same review gate before merge. What is different is the accountability. And that accountability, I think, makes you a better PM on client work too. Because you stop asking "what does the client want?" and start asking "what actually reduces friction?" - and you get very good at telling the difference.