Design documentation looks simple until you're writing it at 11pm and realize you're the only person who can explain the payment settlement logic to the next engineer who touches it. That's when typing becomes too slow. Not because your hands are tired. Because your thinking moves faster than your fingers.
The work changed, but the tools didn't
Code went from something you type to something you describe. The keyboard is still there, but now you're writing intent, not syntax. You're telling an LLM what to build, not building it yourself. Cursor handles the code generation. You handle the English.
That shift created a new bottleneck. It's not keystroke speed. It's the throughput of your thinking into words. Long-form words. Words specific enough that a model can build on them. Words clear enough that code review doesn't derail three days of work. Words that capture the constraint you just realized matters, the one you can only explain by talking through it.
Voice should solve this. It's how you naturally explain logic out loud. But most voice tools were built for transcription, not development workflows. They meter it. They cap it. They assume you'll stay on the free tier for emails and meetings, not 900-word design docs at 11pm.
Why local-first matters for code
Marcus works on payment settlement at a Series B fintech in Stockholm. He's the engineer who understands the full flow. He won't use cloud-based transcription for design docs. Not because he's paranoid. Because code, architecture decisions, internal scale numbers, it all lives in the doc.
Sending that to someone else's server isn't an option. Not for a payment system.
Local-first isn't paranoia. It's structural. When speech-to-text runs on your device, your words never leave. The infrastructure overhead vanishes. The privacy concern vanishes. The cost vanishes. The latency vanishes too, your computer can transcribe as fast as you speak, no network roundtrip, no cloud queue.
That changes the business model. If dictation runs locally with zero variable cost to you, the tool doesn't need to meter it. Wispr Flow charges $14 per month and caps the free tier at 2000 words per day. That's 67 words per minute if you're speaking for 30 minutes straight. One long design doc and you're done for the day.
Recitey's free tier is the same local Whisper engine, uncapped, with no word counter at all. Same accuracy. Same device. No metering because there's no cloud bill to pass through. The paid tier adds cloud-based rewriting and polish, not the dictation itself.
The 11pm moment
Marcus opens a design doc at 11pm. He's got the payment flow clear in his head. The state machine logic. The idempotency keys. The settlement batch timing. He'll lose it if he stops to type. The thought will fragment. So he speaks.
Most voice tools work fine for the first paragraph. Then the free tier cap hits mid-thought. He switches back to typing. The rhythm breaks. Half the doc is dictated, half is typed. The prose becomes choppy. Inconsistent. He saves it and re-reads it the next morning, which means rework.
With no word cap, he just keeps speaking. The whole doc comes out as one thought. It's rough, natural speech always is, full of filler and repetition. But the meaning is intact. The architecture decisions are captured. The constraints are explained. The thinking is preserved. That's the difference between a design doc he can ship to code review and one that needs rewriting.
That's the difference between incident postmortems written the day they happen and ones that get reconstructed three weeks later from Slack threads.
No metering means no fragmentation
The math is simple. A cap creates a decision point. Do I use my word budget on this design doc, or do I save it for tomorrow's Slack explanation? It fragments your thinking into ration-aware sessions.
No cap means no decision. You speak until the thought is done. Then you speak the next thought. Then you're done.
Recitey runs Whisper locally on your device. No meters. No counters. No cloud transcription bill. The free tier is the same engine as the paid tier; the paid tier adds cloud-based rewriting and polish, not the core dictation.
You can dictate a 2000-word design doc, a 500-word PR description, a 1200-word incident postmortem, all on free, all uncapped, all in the same day.
That structural difference compounds. One doc is fine. But five docs a week? Fifty docs a month? That changes how you work. You stop thinking "should I use voice for this?" and start thinking "of course I'll use voice for this." It becomes part of the workflow instead of a rationed feature.
What changes after
This is the moment developers often miss: voice writing isn't faster typing. It's not about words per minute. It's about thinking without stopping.
When you know you're not hitting a cap, the flow doesn't break. When the flow doesn't break, you stay in the thought. When you stay in the thought, the prose stays coherent. Fewer rewrites. Fewer "wait, what did I mean by that?" moments three hours later.
The cycle time shrinks. Design decisions get captured in the moment instead of reconstructed from Slack threads. Incident postmortems get written while the event is fresh instead of weeks later. PR descriptions explain the why instead of listing the what because you had space to think it through out loud.
Cursor's tab-complete handles the code. Recitey handles the explaining. That's the workflow shape that's actually emerging for developers who work with LLMs.
The 11pm design doc gets written. It gets reviewed. It works.