Client
Self-initiated (Speakeazy.pro)
02
Speakeazy — the tool that should have existed.
I narrate audiobooks and hated the hours of character prep before every recording. So I went looking for a tool to do it, found that none existed, and built one myself: through three abandoned prototypes and a two-week ground-up rewrite, launched to real users in January 2026.
01Context
A narrator's unpaid first act.
I record and audition for audiobooks. Every project begins the same way, long before the microphone, with prereading: working through the whole manuscript, sometimes more than once, to learn every character, how they relate, and how each one changes across the book. I need all of it to make voice decisions as an actor.
That work is heavier for narrators than for any other kind of performer. In film or television you play one character and go deep on that one. An audiobook narrator plays everyone: every character, every background, every relationship, and has to hold them consistent for hundreds of pages.
The brief was as open-ended as it gets: I was the client, the user, and the engineer. I wanted the prep done for me so I could get to the part I actually do this for: the performance.
02The problem, named clearly
Prep is the work you don't get paid for.
Audiobook narrators are paid by the finished hour, not the hours worked. Prereading is critical, especially in fiction, and it is entirely unbilled. Every hour spent mapping characters is an hour of margin gone before a single line is recorded.
It's also unforgiving. Get a character wrong early and the cost compounds the deeper you go.
You can't learn on page 200 that the character you've voiced en français for 199 pages is from Paris, Texas.
I went looking for something to carry the load. It was 2025: surely a tool existed. It didn't. Not one product did what I needed, and nothing came close.
The problem: the most critical prep in audiobook narration is also the most tedious and the least paid, and in 2025 no tool existed to do it.
03The approach
Prove it cheap, then build it tight.
The instinctive move was to build the app first. I didn't, because I had no proof AI could actually attribute dialogue and track characters across a full book. So I tested the idea before committing to it.
I built a proof of concept in ChatGPT and confirmed the core was possible. I made two or three more versions on Hugging Face using Llama models, then a full app in React on an early AI-assisted build stack. It ran until I tried to deploy. Vercel fought me at every turn.
A developer friend reviewed it and was blunt: the thing was badly over-architected, and the deployment pain was a symptom of that complexity. His counsel was to stop patching and rewrite from scratch on a tighter stack in Next.js.
Chose to
Build it for myself first. The only user I had to satisfy at the start was me, a real narrator with a specific problem.
Chose to
Validate with a throwaway PoC in ChatGPT before writing an app: prove AI could do the job before betting weeks on it.
Chose to
Design to the value lever, not the pain. Because narrators earn by finished hour, the job wasn't "organize a script." It was "give billable time back."
Chose not to
Salvage the over-architected build. After months in it, I threw it away rather than keep patching a foundation that was the problem.
Chose not to
Defend my own code. When a dev I trusted said it was too complex, I rewrote instead of arguing.
Chose not to
Chase features before a narrator asked. Every post-launch feature came from talking to real narrators, not from guessing.
04How I built it
Three versions to get to one.
No single screen is the hero here. The build itself is the story: three prototypes and a rewrite, each one teaching what the next had to be.
01
The ChatGPT proof of concept
The cheapest possible test of the riskiest assumption. It proved AI could identify characters and attribute dialogue reliably enough to build on, before I wrote a line of product code.
02
The over-architected first app
A working-on-my-machine app that couldn't be deployed. It cost months and never launched. But it defined exactly what "too clever" looked like, which made the rewrite fast.
03
The shipped Next.js rebuild
Rebuilt from zero over a two-week holiday on a tighter stack. It deployed, worked for real users, and went live in January 2026.
05Outcomes
From nothing to live, solo.
Prototypes to product
3 → 1
Three throwaway versions before one shipped rebuild.
Broken build to live app
2 weeks
A ground-up Next.js rewrite over one holiday break.
First user
Days
After launch, found Speakeazy by asking ChatGPT whether such a tool existed.
Since launch I've been adding what narrators actually ask for: character arcs that track across an entire series, and persistent color codes so the villain and the hero keep their colors across every project. On performance: a short story analyzes in minutes, a novel like The Great Gatsby in about 20–25, and even the longest books finish in a few hours, set-and-forget.
06Reflection
What I'd reverse. What I carried forward.
The decision I'd reverse: the over-architecture. I let an early build get far more complex than the problem deserved, and it cost me months and a deployment I could never make work. The tell was there early. I just didn't have the discipline yet to keep it simple.
The surprise: that the gap was total. I assumed that in 2025 someone had built this; the real surprise was that no one had, and that the first person to find my version was sent there by an AI.
What I carried forward: aim AI at the tedious middle so the human gets to the craft. It's the whole thesis of Speakeazy, and it's the lens I now bring to every tool I build.
Previous case
Precocity — the ten‑year build.