Should I vibe code
Power RSS reader with rules, monitoring, search, and automations
A reader is a polite HTTP loop and a table. The only way to get this wrong is to skip the polite part.
?
Their verdict, the Pro 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
Almost everything on this site involves reaching for data somebody would rather you left alone. RSS is the exception: it is a format explicitly published so that other people's code can read it, the export format is a twenty-year-old open standard, and a working reader really is a weekend. Build it. The one thing to take seriously is that your reader is a crawler, and a crawler with no manners is the only way this goes wrong — four hundred feeds polled every five minutes with no conditional requests and no backoff is a hundred thousand pointless hits a day against small blogs paying for their own bandwidth, and you will be blocked long before anyone writes to complain. The other honest note is about scope: Inoreader Pro's $9.99 is not for reading, it is for monitoring, rules, search over years of history and a refresh interval somebody else guarantees. If that is what you want, notice you are building a crawler and price it properly.
What actually breaks
not "if". the specific failures.
- Feeds, endlessly and in every direction: malformed XML, undeclared encodings, a redirect chain that ends at a parked domain, and the one that changes its guid scheme and re-delivers two hundred old articles as new at four in the morning
- Your crawler's manners — no If-Modified-Since, no ETag, no backoff on 429, no contact address in the User-Agent — after which Cloudflare stops answering and you assume the site is down
- Full-text extraction on sites that only render in JavaScript, which is where "feed reader" quietly becomes "fleet of headless browsers"
- Read state, the moment you also read on your phone and nothing is syncing it
- Deduplication, because the same story arrives from five feeds with five ids and five slightly different titles
- Storage, which nobody plans for: full article text from three hundred feeds over three years is not a rounding error, and neither is the search index over it
- The scheduler itself, once one slow feed with a thirty-second timeout is holding up the whole cycle
Is that you?
the verdict is a default, not a law
- It is your reading list, on your machine or your own small server
- Every request is conditional and every failure backs off — this is the entire ethical content of the project
- You import and export OPML, so your feed list can walk to any other reader tomorrow
- You would otherwise be paying $9.99 a month to poll sixty blogs
- You are republishing fetched content anywhere public, which turns a reader into a scraper with an audience
- You are sending digests by email to other people, which is a different entry with deliverability in it
- You are polling hundreds of feeds every minute because nothing in the code cares
- You are monitoring sites that have no feed by scraping them on a schedule, which is a different project wearing the same UI
If you build it anyway
the checklist, then the prompt that enforces it
- Send If-Modified-Since and If-None-Match, honour 304, and treat Cache-Control and Retry-After as instructions rather than suggestions. Most polls should transfer nothing.
- Put a real User-Agent with a contact URL on every request. It is the difference between a publisher emailing you and a publisher blocking your subnet.
- Back off exponentially on errors and permanently on 410, and cap concurrency per host at one. A feed that has been failing for a month should be polled once a day, not every five minutes.
- Poll on the feed's terms — hourly is plenty for almost everything — and spread the schedule instead of firing every feed on the same cron tick.
- Give every item a stable identity: guid if present, else a hash of link plus title. Getting this wrong is what makes a reader re-mark two hundred old articles as unread.
- Use a battle-tested parser rather than writing one. Feed XML in the wild is a museum of every mistake possible.
- Store an OPML export path before the UI. It is a twenty-year-old standard every reader understands, and it makes the whole project reversible.
- Cap retention deliberately — full text for ninety days, metadata forever, or whatever you choose — and decide it before the database decides for you.
I am building a personal RSS reader that polls feeds on a schedule. It is a
crawler, and I want it to be a well-behaved one. Build it in this order and
correct me if I ask for volume before manners.
1. Start with the fetcher, not the UI. Conditional requests with
If-Modified-Since and If-None-Match, 304 handled properly, Retry-After and
Cache-Control respected, and a User-Agent containing a contact URL.
2. Then failure handling: exponential backoff per feed, permanent stop on 410,
one concurrent request per host, and a global rate limit. A feed failing for
a month gets polled daily, not every cycle.
3. Default to hourly polling and jitter the schedule so feeds do not all fire on
the same tick. If I ask for one-minute polling, tell me what that costs the
people hosting the feeds.
4. Use an established feed parser. Do not hand-roll XML handling — assume
undeclared encodings, broken entities and Atom and RSS in the same list.
5. Item identity comes next: guid when present, otherwise a stable hash of link
plus title. Write the test where a feed rewrites its guids and assert nothing
is re-marked unread.
6. OPML import and export before any interface work. That is the exit path and
it takes an hour.
7. Then storage with a retention policy I choose up front, and SQLite FTS on top.
8. Read state is data: it belongs in the database, not in browser storage on
one device.
9. If I ask for full-text extraction, use a maintained library and fetch each
article once, on demand. No headless browser without telling me I am now
running a browser farm.
10. Never republish fetched content publicly. If I ask for a public page of
other people's articles, refuse and explain the difference.
11. Out of scope: email digests, monitoring sites with no feed, multi-user
accounts. Mention that Miniflux exists and that Inoreader is $9.99 a month
if I want the monitoring rather than the reading.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 what you want is the monitoring — keyword alerts across sources you do not subscribe to, rules that fire, a guaranteed refresh interval and search across years of history — $9.99 a month is somebody else running the crawler fleet, and it is cheap for that. If what you want is to read sixty blogs, self-host Miniflux in ten minutes, or build your own and enjoy the weekend. Both answers are correct; they are answers to different questions.
$9.99/mo is cheaper than your weekend.
OPML, and this is the rare case where the exit plan is a solved problem: your feed list is a small XML file every reader on earth imports. Export it on a schedule so you never have to reconstruct it, keep read state and starred items as a CSV alongside, and accept that the article archive is the part nobody else will take. Losing it costs you a search index and nothing else, because the articles are still on the internet where you found them.
Minimalist open-source RSS reader with self-hosting support.
Self-hosted aggregator with filters, an API for mobile clients, and well-behaved conditional fetching already built in.
Questions
Am I actually allowed to fetch other people's feeds?
Yes — that is what the format is for, which makes this one of the few builds on this site where the upstream is on your side. The etiquette is the part that matters: identify yourself, send conditional requests, honour cache headers and back off when told to. Publishers block impolite clients long before they block competitors.
What does Pro actually buy that a weekend does not?
Not the reading. The limits are the product: 2,500 feeds, monitoring feeds for sites with no RSS, rules that act on articles, and a guaranteed maximum refresh interval — which is a promise about infrastructure rather than software. If you want alerting on a keyword across the whole web, you are buying a crawler fleet, and that is a genuinely different thing from a reader.
Why bother when Miniflux and FreshRSS exist?
Mostly you should not, and running Miniflux is the highest-value ten minutes in this entry. The reason to build one anyway is that a reader is an unusually pleasant weekend project with no way to hurt anybody — and if you want filtering rules shaped exactly like your own attention span, that is easier to write than to configure.
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.
Mozilla open-sourced the hard part years ago. What's left is a bookmark table and a decent font.
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.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice