Should I vibe code
Save readable versions of permitted pages, highlight them, and search the archive
Mozilla open-sourced the hard part years ago. What's left is a bookmark table and a decent font.
?
Their verdict, the Premium 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
The only interesting half of a read-later app is extraction — getting the article out of a page consisting mostly of newsletter modals — and Mozilla open-sourced exactly that, because it is the code behind Firefox's reader mode. Bolt it to a save endpoint, add SQLite full-text search over what comes back, and the homemade version is not a compromise; for a single reader it is arguably better, because you can keep the whole archive on a disk you own. Two caveats, both mild. Extraction fails precisely where you want it most, on paywalled and JavaScript-only sites, and the tempting fix — handing your archive server a copy of your session cookies so it can fetch as you — trades a small annoyance for a credential store you did not mean to build. And a private archive of full article copies is your browser cache with a memory, which is fine; publishing it is a republication of other people's work, which is a different thing with a different name.
What actually breaks
not "if". the specific failures.
- Extraction, on the sites you care about most: paywalls, consent walls, and pages that render entirely in JavaScript and hand a server-side fetcher an empty shell
- The temptation that follows, which is to give your saving service your session cookies so it can fetch as you — at which point a weekend project is holding logged-in credentials for every publication you read
- Images, which most saved copies hotlink rather than store, so the archive quietly rots from the pictures inward as sites reorganise
- The archive being the only copy, kept on one machine, with a schema that made sense to you in week one
- Reading position and highlights, once you read on two devices and nothing is reconciling them
- Boilerplate leaking in — related-article rails, cookie banners and "sign up for our newsletter" landing in the middle of paragraph four, which is what the extraction library is fighting and does not always win
- The moment the archive becomes public, because a private cache and a republishing site are the same code with a different verdict
Is that you?
the verdict is a default, not a law
- It is your reading list, on your hardware, read by you
- Saving happens from a browser extension using the page already rendered in front of you, rather than a server refetching it
- The extractor is a maintained library, not something the agent wrote from first principles
- You export the archive somewhere readable — HTML or markdown files — on a schedule
- The archive is public, or shared with anyone beyond you, which is republication of somebody else's writing
- You are storing session cookies or logins for publications so the fetcher can get past paywalls
- You are saving thousands of URLs a day on a schedule, which is a crawler wearing a reading app's clothes
- You are selling it, at which point you have taken on other people's reading histories, and reading history is a profile
If you build it anyway
the checklist, then the prompt that enforces it
- Use Mozilla's Readability or trafilatura for extraction. This is the one component where a hand-rolled version is obviously worse, and both have absorbed years of real-world weirdness you have not seen yet.
- Save from the browser, not from the server. An extension that captures the DOM you are already looking at handles paywalls, consent walls and JavaScript for free, and never needs a copy of your cookies.
- Keep the original URL, the fetch timestamp and a content hash next to every saved article, so you can always tell what you have and when you got it.
- Download images alongside the text if you intend to keep the archive for years. Hotlinked pictures are the first thing to disappear.
- Make the archive files, not just rows: one HTML or markdown document per article on disk, with the database as an index over them. That single decision makes the whole project reversible.
- Put full-text search on SQLite FTS and stop there. Nothing at personal scale needs more, and a search cluster is how a weekend project acquires an ops burden.
- Keep it private and authenticated even though it is only for you — a public archive of extracted articles is a republication, and it is also excellent bait for crawlers.
I am building a personal read-later archive: save a URL, store a clean readable
copy, highlight it, search it. One reader, me. Build it in this order and stop
me if I ask for the paywall feature early.
1. Use a maintained extraction library — Mozilla Readability or trafilatura —
and do not write your own boilerplate stripper. Show me its failure cases
before we build anything on top.
2. Capture from the browser. Write a bookmarklet or extension that sends the
already-rendered DOM to my archive, rather than a server that refetches the
URL. Explain why this handles consent walls and JavaScript pages for free.
3. If I ask you to get past a paywall by storing my session cookies, refuse.
Say plainly that it turns a reading app into a credential store for every
publication I subscribe to, and offer the extension capture instead.
4. Store each article as a file on disk — HTML or markdown — with the original
URL, fetch time and a content hash. The database is an index over the files,
never the only home of the text.
5. Build export before reading features: a folder of articles plus a CSV index
that opens without the app running.
6. Then search, using SQLite FTS. No external search service.
7. Then highlights and reading position, stored against a stable article id so
they survive a re-fetch or a re-extraction.
8. Fetch images and store them locally if I ask for a long-lived archive.
Warn me about the disk cost before you enable it.
9. Everything is private and authenticated even though I am the only user. If I
ask for public sharing of saved articles, tell me that is republishing
somebody else's writing and is a different project.
10. Be a polite client: one request per save, a real User-Agent, no crawling
links found inside saved pages, no bulk re-fetching on a schedule.
11. Out of scope on purpose: mobile apps, sync between devices and
text-to-speech. Note that Instapaper is $5.99 a month and that the free tier
already covers saving and reading if that is all I want.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
If you read mostly on a phone, in tunnels, with text-to-speech, the $5.99 is buying a mature mobile app and offline sync, and those are exactly the parts a weekend does not produce. Note the free tier already covers saving and reading — Premium is search, unlimited highlights and speech. If you read on a laptop and want the archive to be yours in ten years, build it, or run wallabag and skip the weekend.
$5.99/mo is cheaper than your weekend.
One folder of HTML or markdown files, named by date and title, plus a CSV index of URL, saved-at, tags and highlights. Build that on day one and the app is disposable in the good way — Instapaper, wallabag and every future thing will import a folder of documents, and so will grep. The failure mode to avoid is the article text living only as a column in a database whose schema you no longer remember.
Self-hosted read-later application with extraction, tags, highlights and mobile clients already built.
Mozilla's standalone extraction library — the code behind Firefox reader mode, and the hard half of this project.
Questions
Is saving full copies of articles legal?
Keeping a personal copy of something you are entitled to read is broadly how every browser cache and reader mode has always worked, and that is the shape this project should keep. It changes when the archive stops being personal: sharing extracted copies publicly, or serving them to other users, is republishing somebody else's work, and no amount of "but I only saved it" changes what a publisher sees.
Why does extraction fail on the sites I most want?
Because those sites are built to make it fail. Paywalls serve a teaser to anything that is not a logged-in browser, consent walls block until a script runs, and single-page apps hand a server fetcher an empty container. Capturing from the browser you are already reading in sidesteps all three, which is why every good read-later tool ships an extension rather than a URL box.
Isn't this just bookmarks with extra steps?
The difference is whether it survives the source. A bookmark is a pointer that stops working when a site reorganises or shuts down; a saved copy is still there. That is the entire reason to build this rather than use the browser's reading list — so if your version does not store the text, you have built bookmarks with extra steps.
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.
Save a URL, tag it, search it. This has been a solved weekend since 2004.
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