Should I vibe code
Read-it-later app with highlights, RSS, PDFs, and spaced review
Saving is the weekend. Finding the thing you saved six years ago is the product you will not finish.
?
Their verdict, the Readwise (includes Reader) 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
Reader is four products wearing one coat, and only the first is a weekend. Fetch a URL, run it through an extractor, render it in a decent serif — working before lunch. Then you notice the rest: PDFs with annotations anchored to a page, EPUBs with a reflowing renderer, YouTube with a transcript scrubbed against the playhead, Twitter threads, and Kindle highlights that arrive only because something logs into an Amazon page and scrapes the notebook, since there is no API and never has been. Each of those is a separate parser with a separate decade of edge cases. Meanwhile the part you would genuinely miss is not capture at all — it is retrieval: instant full-text search across four thousand documents, offline, on a phone, with every highlight flowing out into Obsidian and back as a daily review. Nothing here is dangerous. The predictable outcome is that you build the ingestion, ship the reading view, and never build the retrieval, and retrieval was the entire reason you saved anything.
What actually breaks
not "if". the specific failures.
- Kindle sync, which is not an integration but a scrape of an authenticated Amazon page — Amazon changes the markup whenever it likes and owes you no notice
- PDF highlighting, which needs a text layer your scanned papers do not have, and page coordinates that move the moment you re-render
- EPUB, where the highlight has to survive a reflow at a different font size on a different device — CFI ranges exist for exactly this reason and they are not fun
- Search, which is fine over five hundred documents in SQLite FTS and a different engineering problem over forty thousand with an offline copy on a phone
- The outbound pipe into Obsidian or Notion, where a re-sync without stable highlight IDs duplicates six years of marginalia in one pass
- Text-to-speech, the feature people actually pay for, which arrives with a per-character invoice attached
- Feed and newsletter ingestion, because the moment your reader also does RSS it inherits every crawler manner problem a feed reader has
Is that you?
the verdict is a default, not a law
- You want one lane — articles into clean Markdown, or Kindle clippings into your notes — rather than a library
- You read on a laptop, so the offline mobile client that carries the whole archive never has to exist
- The output is files in a folder you already back up, and the app is just a viewer over them
- The highlights are meant to feed a note system you rely on, and a bad re-sync would pollute it faster than you could notice
- PDFs and EPUBs are the point, because that is two more renderers and an anchoring problem, not one more format
- You want it on a phone, offline, with search — that is the actual product and it is nowhere near multi-day
- This would become the only surviving copy of pages, papers or newsletters that later disappear
If you build it anyway
the checklist, then the prompt that enforces it
- Give every highlight a stable ID at creation and never regenerate it. Every downstream sync dedupes on that ID, and without it a resync duplicates your whole archive.
- Keep the original bytes — the fetched HTML, the PDF, the EPUB — next to the extracted text. Re-extraction is cheap; re-fetching a dead URL is impossible.
- Anchor highlights to quoted text plus context, not to character offsets or page coordinates, because your extractor will change and offsets rot silently.
- Build search on day one against a fake corpus of ten thousand documents, so you find out about the index size before it holds anything you care about.
- Treat Kindle import as a scraper: expect it to break, fail loudly rather than importing nothing, and keep the last successful payload on disk.
- Put a hard cap and a visible running total on any text-to-speech or LLM feature before you wire it to a whole library.
I am building a personal reader: save articles, PDFs and EPUBs, highlight them,
and sync those highlights into my notes. Low risk, high abandonment. Protect
retrieval and the archive before you build anything enjoyable.
1. Start with search, not capture. Generate ten thousand fake documents, build
the full-text index, and show me query latency. If the design will not hold
forty thousand documents, say so now rather than in year three.
2. Then build export. Every document leaves as Markdown plus its original file,
highlights inline, into a folder I name. That folder is the product.
3. Give every highlight a UUID at creation, persisted forever. Never derive an
ID from text, offsets or position. Downstream syncs dedupe on that UUID.
4. Anchor a highlight to a quoted string plus leading and trailing context.
Do not anchor to character offsets, page numbers or PDF coordinates.
5. Always keep the source bytes — raw HTML, the PDF, the EPUB — alongside the
parsed text. Re-extraction later must never require re-fetching.
6. Take formats one at a time and finish each. HTML articles first. Do not
start PDF annotation or EPUB reflow until article capture and export both
round-trip cleanly.
7. For Kindle import, treat it as scraping an authenticated Amazon page,
because that is what it is. On a parse failure, stop and tell me — never
write a partial or empty import over existing highlights.
8. Any sync into Obsidian, Notion or files must be idempotent and dry-runnable.
Show me the diff before the first real write.
9. Do not write a device sync engine. Use a synced folder or an existing
syncing database, and store read position per device.
10. Put a hard spend cap and a visible token counter on text-to-speech and any
LLM summarisation before either touches more than one document.
11. Out of scope, and say so instead of faking it: an offline mobile app,
e-ink clients, and a shared multi-user library. If I ask for the phone
version, tell me that is the actual product and Readwise Reader costs
thirteen dollars.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 read on a phone, or your library already has thousands of things in it. Thirteen dollars a month buys the two parts you will not finish — fast offline search across the whole archive on every device, and a parser somebody else maintains against PDFs, EPUBs, YouTube and Amazon's HTML every single week. If it is only the article queue you want and the subscription is the objection, Wallabag and Karakeep both self-host and both already have search.
$12.99/mo is cheaper than your weekend.
Keep the archive as files, not rows: one folder per document with the original bytes, a Markdown rendering, and a sidecar of highlights carrying stable IDs and quoted text. That shape imports into Readwise, Wallabag, Obsidian and Zotero without a migration script. The cautionary example is Omnivore, whose hosted service closed in November 2024 and taught a lot of people what their highlights were actually stored in.
Open-source read-it-later app with article extraction and self-hosted reading workflows.
Self-hostable bookmark and read-later app with full-text search, archived copies and AI tagging.
Minimalist self-hosted feed reader, the honest answer when the RSS half is all you actually wanted.
Questions
Matter is rated demo-only too. What is different here?
Matter's problem is the parser arms race and the phone. Reader's problem is scale and formats: it is a library, not a queue, and the features that make it worth paying for — full-text search across everything, PDF and EPUB annotation, highlights syncing out and never duplicating — all get harder as the archive grows, which is the opposite of how side projects age.
Why is Kindle import singled out?
Because Amazon publishes no highlights API. Every tool that syncs Kindle highlights is either parsing My Clippings.txt off the device or driving an authenticated session against read.amazon.com and reading the notebook page. Both are scrapes. Yours will break, and it will break silently unless you make it fail loudly.
Is any part of this genuinely better homemade?
The outbound pipe. Highlights leaving a reader and landing in your own files, in a format you chose, with IDs you control, is better when you build it — because the value is entirely in the format and nothing in the UI.
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.
Import your own highlights, resurface them on a schedule. Genuinely a small program.
Parsing one article is a Saturday. Parsing the web is a subscription you pay in weekends, forever.
A reader is a polite HTTP loop and a table. The only way to get this wrong is to skip the polite part.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice