Should I vibe code
RSS reader and research feed for websites, newsletters, and alerts
RSS is a solved format and a fetch loop. Reclaim your reading.
?
Their verdict, the Pro price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-03.
?
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
Parsing feeds, deduping and marking read is a genuinely small program, and the result is a reader that behaves exactly the way you want.
What actually breaks
not "if". the specific failures.
- Feeds in the wild, which are RSS, Atom, JSON Feed and several confidently malformed variants of each
- Item identity, where a feed without stable GUIDs makes every refetch look like new articles
- Polite fetching, since a reader that ignores caching headers is a reader that hammers small sites
- Feeds that change URL or die, quietly reducing your reading list without telling you
- Read state across devices, which is the one thing that makes a reader feel like a product
The honest failure is a morning with four hundred unread items from one blog. The feed does not set GUIDs and regenerates its dates on each build, so every time the site deploys your reader concludes that all forty posts are new. Nothing is broken on either end — the feed is technically valid and your matching is reasonable — and the outcome is that the one source you most wanted to follow is now the one you have muted.
Is that you?
the verdict is a default, not a law
- You use an established feed parser rather than reading XML yourself
- Item identity falls back sensibly when GUIDs are missing
- You honour caching headers and back off on errors
- You are parsing feed XML by hand
- The fetcher ignores ETag, Last-Modified and retry-after
- Dead feeds fail silently and vanish from your reading
- You are fetching hundreds of feeds on a tight interval from one address
If you build it anyway
the checklist, then the prompt that enforces it
- Use a maintained feed parser. The formats are multiple and real-world feeds violate all of them — this is not a place to be original.
- Derive item identity from GUID, then link, then a hash of title plus content. Feeds without stable GUIDs are common and are what produce phantom unread floods.
- Send If-None-Match and If-Modified-Since, honour 304, and respect retry-after. A personal reader should be invisible to the sites it reads.
- Back off exponentially on failures and surface a feed that has been failing for a while, rather than dropping it silently.
- Store read state server-side if you read on more than one device, since that is the feature that makes it usable.
- Keep an OPML export, because a reading list is portable by convention and should stay that way.
Before you build an RSS reader, apply these and push back if I ask you to break them. 1. Use an established feed parsing library that handles RSS, Atom and JSON Feed. Do not parse the XML yourself — real feeds are malformed in creative ways and this is solved. 2. Derive item identity in order: GUID if present and stable, then the link, then a hash of title plus content. Tell me that feeds which regenerate GUIDs or dates on every site build will otherwise present every old post as new, and that this is the single most common reason people abandon a homemade reader. 3. Send If-None-Match and If-Modified-Since on every fetch, handle 304 properly, and respect Retry-After. A personal reader should be invisible to the sites it polls. 4. Back off exponentially on failure, and surface feeds that have been failing for several days rather than letting them silently disappear from my reading. 5. Detect permanent redirects and update the stored feed URL. 6. If I read on more than one device, store read state server-side — that is what makes a reader feel finished. 7. Support OPML import and export, because a reading list is portable by convention. 8. Sanitise feed content before rendering. It is HTML from arbitrary sources. 9. Out of scope unless I ask: full-text extraction of linked articles, recommendations, newsletters by email, sharing.
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
$7 a month buys sync, mobile apps and a fetcher someone else keeps polite. RSS is a genuinely solved format and a personal reader is a satisfying build — just use a real parser and honour caching headers, which is most of the difference between a good citizen and a nuisance.
OPML for the subscription list and a simple table for read state. The subscriptions are the asset and OPML is the universally accepted format, so a reading list built here can move to any reader ever written.
Mature self-hosted RSS aggregator and reader.
Questions
Why do some feeds show every post as new?
Because the feed does not provide stable identifiers. Static site generators frequently regenerate GUIDs or publication dates at build time, so a redeploy makes every item look different to a reader matching on those fields. Falling back to the link, and then to a content hash, absorbs almost all of it.
Does honouring caching headers really matter for one reader?
For one reader polling a handful of feeds, barely. It matters because the cost falls on small sites — a personal blog on cheap hosting notices readers that refetch the whole feed every fifteen minutes. Sending conditional requests is a couple of lines and means your reader costs the sites you like nothing.
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.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice