Should I vibe code
Read user-provided text and documents aloud with a small set of licensed or local voices
Browsers have had a speech synthesiser since 2014. The subscription is a nicer accent and a working PDF parser.
?
Their verdict, the Lite price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Browsers have shipped a speech synthesiser since 2014 and speechSynthesis.speak() is one line, which means the reading part of a reading app is already free. What the subscription covers is the paperwork around the voice: OCR for scanned pages, extraction from PDFs that were laid out for print rather than for reading, word-level highlighting that stays in sync with the audio, a resume position that survives moving from phone to laptop, and voices you are licensed to export as an MP3. None of that touches anybody but you — text goes in, sound comes out, and the worst outcome is a machine mispronouncing your surname. So build it. The one decision worth making on purpose is whether the text leaves your machine, because a local Piper voice is free, offline and yours, and swapping it for a hosted API quietly turns a reader into a pipeline that posts your documents to somebody else's server for the sake of a better accent.
What actually breaks
not "if". the specific failures.
- PDF extraction, which is where this project actually lives — two-column papers get read straight across the gutter, running heads and page numbers arrive mid-sentence, and every hyphenated line break becomes two words
- Word highlighting, the moment you move from a voice that emits boundary events to one that hands back a finished audio file with no timings
- Pronunciation of names, acronyms, units and years, permanently, unless you build somewhere to correct them
- Resume position, the first time you listen on a phone and then open the laptop
- The voice licence, if you export an MP3 and publish it — synthesis APIs are licensed for use, and redistribution is a separate clause somebody has to go and read
- Very little else. This is one of the few entries where the failure list is short and none of it lands on a stranger
Is that you?
the verdict is a default, not a law
- The text is yours and the audio never leaves the machine that made it
- A local voice is good enough, or you have consciously decided you are fine posting these documents to a hosted API
- You want a reader rather than a publishing pipeline
- You need the one thing the product does not do — a shortcut, an odd file format, a pronunciation dictionary for your field
- You are generating audio for publication and have not read the voice provider's redistribution terms
- Someone depends on it as assistive technology and there is no fallback for the week your build is broken
- The documents are confidential and the plan was to POST them to a hosted endpoint without checking what it retains
If you build it anyway
the checklist, then the prompt that enforces it
- Start local. Piper or the browser's own synthesiser costs nothing, works offline and never sees your documents; treat a cloud voice as an upgrade you justify rather than the default you reach for.
- Build the extractor before the player. Text quality is the whole product — a perfect voice reading a mangled PDF is worse than a robotic one reading clean text, and nine tenths of your time goes here.
- Keep a pronunciation dictionary from day one, as a plain file you can edit. Every reader ends up needing one, and retrofitting it after a thousand documents is miserable.
- If you export audio, record which voice and which provider produced each file, and read the redistribution clause once, up front. It is a five-minute job that stops being possible after you publish.
- Cache synthesised audio keyed on the text rather than the document. Re-reading a paragraph should never cost a second API call, and the cache is also what makes offline playback work.
I am building a text-to-speech reader for my own documents. Constraints first, and push back if I ask you to skip one. 1. Default to local synthesis — Piper, or the browser's speechSynthesis API. Do not add a hosted TTS provider until I ask, and when I do, say plainly that my document text will be sent to that provider. 2. Build text extraction before playback and treat it as the main event. PDFs first: handle two-column layouts, strip running heads and page numbers, and rejoin words split across a hyphenated line break. 3. Show me the extracted text before you speak it. A visible intermediate representation is how I find out the parser ate a footnote, and it is free. 4. Put a pronunciation dictionary in a plain editable file from the first version, applied before synthesis. Names and acronyms are the failure I hit on day one, every time. 5. Keep playback position per document in local storage, and make resume survive a crash before you make it work across devices. 6. Cache synthesised audio keyed on a hash of the exact text sent. Never bill me twice for a paragraph I already heard. 7. If I add a cloud voice, keep the provider behind one interface with a local fallback, and never write document text to a log file or a console. 8. If I ask for MP3 export, stop and ask what I intend to do with the files. If the answer is publish, tell me to check the voice licence for redistribution before you write the exporter. 9. Out of scope: OCR of scanned images, voice cloning, and anything that speaks in a named person's voice. Say so rather than half-building them.
That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
You need OCR on scanned or photographed pages, or you rely on this to read for you and cannot afford a broken week. Fourteen dollars a month buys a maintained document pipeline and voices you are licensed to export, and when this is assistive technology rather than a toy, that reliability is the whole product and worth paying for.
$13.9/mo is cheaper than your weekend.
There is barely anything to exit. The documents were always yours, the audio is files in a folder, and the synthesiser is a swappable dependency behind one function. Keep the pronunciation dictionary as a plain file and you can move to a different engine, or back to the product, in an afternoon.
Active community continuation of the fast local Piper text-to-speech engine.
Browser extension that reads the current page aloud, and the closest open-source shape to the product.
Tiny formant synthesiser covering a hundred languages; the free floor this whole category is priced against.
Questions
Is the browser's built-in voice really good enough?
For reading your own notes back to yourself, usually yes, and it costs nothing and works offline. Where it falls down is long-form listening, because flat prosody gets tiring after twenty minutes, and control, because the available voices depend on the operating system rather than on you. A local neural voice like Piper closes most of that gap and still never sends a word anywhere.
Why is this SHIP IT when the product is rated KINDA upstream?
The two sites are asking different things. They are judging whether you can reproduce NaturalReader, and you cannot — the OCR, the mobile apps and the licensed voice catalogue are real work. We are judging whether you should build the version you would actually use, which is much smaller and has no blast radius at all. Here the consolation build is the point rather than the disappointment.
What about generating audio to publish — an audiobook, a video, a podcast?
Different project, different answer. The moment the output is published rather than played, you are in licensing territory: most synthesis APIs distinguish between using the audio and redistributing it, some require attribution, and some exclude commercial use on the cheaper tiers. Read the clause before you upload, because it is the one part of this you cannot fix afterwards.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
Every episode you have shipped is thirty minutes of clean, isolated reference audio for cloning your guest's voice.
Mozilla open-sourced the hard part years ago. What's left is a bookmark table and a decent font.
whisper.cpp plus a drop zone is the whole app. The only real question is who else was on the recording.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice