Should I vibe code
Save articles and newsletters into a clean reading queue with highlights and notes
Parsing one article is a Saturday. Parsing the web is a subscription you pay in weekends, forever.
?
Their verdict, the Matter Premium (monthly) 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
Fetch a URL, run it through a readability library, store the text, render it in a good serif: that is a Saturday, and the result is genuinely pleasant to use. The rest of Matter is where the years go. Newsletter ingestion means operating an inbound mail address per user and parsing whatever Substack’s templating did this week. Parsing means losing a permanent, per-site arms race against paywalls, lazy-loaded images and consent walls. And the part you actually wanted — reading on a phone, offline, on a train — is a mobile app with a sync engine, which is not the project you signed up for. The risk here is close to zero. The abandonment rate is close to one, and the thing you lose when you abandon it is four years of saved articles.
What actually breaks
not "if". the specific failures.
- Parsers, endlessly. Every site is a special case, and the ones you read most are the ones with the most aggressive consent walls and the most creative lazy-loading
- Newsletter ingestion: an inbound address that is discoverable by definition, which turns your reading queue into a spam target and your HTML parser into an attack surface
- Sync. Two devices, one read position, edits made offline — the oldest hard problem in software, wearing a reading app as a costume
- What you actually stored. Images hotlinked rather than saved, paywalled sections silently missing, and you find out months later when the original has gone
- Text-to-speech, the feature people genuinely pay for, and the one with a per-character bill attached
- The archive itself. Four years of saved articles and highlights are the entire point of the app, and they live in whatever schema you wrote in the first hour
Is that you?
the verdict is a default, not a law
- It is yours, it runs locally, and losing the queue would annoy you rather than cost you anything
- You read on a laptop, so the mobile and offline problem never arrives
- You want one narrow thing — RSS into a clean queue, or highlights into your notes — rather than a reading platform
- You expect it to replace the app on your phone, because that is a different and much longer project
- Highlights feed something you care about, and losing them would cost real work
- You would expose an inbound newsletter address with no rate limit and no size cap
- The archive is the only surviving copy of pages that have since gone offline
If you build it anyway
the checklist, then the prompt that enforces it
- Store the fetched HTML as well as the extracted text. Re-extraction is free later; re-fetching a page that has been deleted is not.
- Export before features: one Markdown or JSON file per article, highlights inline, written to a folder you already back up.
- Treat the newsletter address as hostile input — per-sender rate limits, a hard size cap, no remote content fetching by default, and rotate it if it leaks.
- Save images locally at capture time, or accept that half your archive is a set of links to other people’s servers.
- Anchor highlights to quoted text, not character offsets. Your parser will change and offsets will rot silently.
- Reuse an existing sync substrate — a git repo, a synced folder, CouchDB — rather than writing merge logic for read positions.
- Assume you will abandon it. Make the on-disk format something a human can read in a text editor five years from now.
I am building a personal read-later app: save articles, parse them, read them, highlight them. It is low risk and high abandonment, so protect the archive first. 1. Build export before capture. Every article writes out as Markdown with YAML front matter — url, title, saved date, tags — and its highlights inline, into a folder I choose. That folder is the product; the app is a viewer over it. 2. Store the raw fetched HTML alongside the extracted text, always. I want to re-extract later without re-fetching pages that may be gone. 3. Save images and other assets locally at capture time rather than hotlinking, and tell me what that costs in disk. 4. Use an existing readability extractor rather than writing selectors per site, and when extraction fails, keep the raw page and mark the article as unparsed instead of storing an empty body. 5. Anchor highlights to a quoted text fragment plus surrounding context, never to character offsets into the parsed body. 6. If I ask for newsletter ingestion, treat the inbound address as hostile: per-sender rate limits, a hard message size cap, no remote content fetching, HTML sanitised before it is ever rendered, and an easy way to rotate the address. Explain why before you build it. 7. Do not write a sync engine. Use a synced folder, a git repo or an existing database that syncs, and store the read position as a per-device record rather than a shared mutable field. 8. Keep it single-user and local. If I ask to host it for other people, stop and tell me I have just taken on other people’s reading history. 9. Out of scope, and say so rather than faking it: text-to-speech, an AI co-reader, and native mobile apps. If I want to read on a phone offline, tell me that is the actual product and I should look at Matter, Readwise Reader or Wallabag first.
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 your phone. Eight dollars a month buys the two things you cannot reasonably build — a polished offline mobile reader and a parser that somebody maintains against the whole web every week — and Matter’s free tier already covers an uncapped read-later library. If the objection is the subscription, Wallabag is open source, self-hostable and has been quietly doing this for a decade.
$7.99/mo is cheaper than your weekend.
The URLs are the durable asset. Keep a flat list of url, saved date, tags and read state, plus highlights stored as quoted text, and Wallabag, Readwise Reader, Instapaper and Matter itself will all take it. Omnivore is the cautionary tale worth reading first: the hosted service closed in November 2024 and everyone who had treated it as a permanent library found out how portable their highlights were on somebody else’s schedule.
Self-hostable read-later application with mature extraction rules, mobile clients and real exports.
Mature self-hosted feed reader, the right answer when what you want is RSS rather than a reading platform.
Open-source read-later app whose hosted service shut down in November 2024; self-hosting is now the only option.
Questions
This is basically harmless. Why not ship-it?
Because the verdict is about whether you will end up relying on it, and the honest answer is a queue you stop opening once the parser breaks on your three favourite sites. The gap is the phone: an offline mobile reader with sync is the actual product, and it is nowhere near the weekend that canivibecodeit is scoring.
What is the one part worth building?
The pipe into your own notes. Highlights out of a reader and into Obsidian, a git repo or plain files is genuinely better homemade, because the value is the format you chose and not the reading UI.
Is newsletter ingestion as easy as it sounds?
Receiving the mail is easy; everything after is not. You are running a public address that will be found by spam, parsing marketing HTML that assumes a mail client, sanitising it before rendering it, and rebuilding the parse each time a platform changes its template.
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