Should I vibe code
Fast hosted feed reader with filtering, comments, and full-text reading
Everything BazQux charges $30 a year for is the part that isn't RSS. The RSS part is an evening.
?
Their verdict, the Standard 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
Build it. A reader is a polling loop, a parser and one boolean per article, the export format is a twenty-year-old open standard, and yours will be tuned to how you read rather than to what keeps you scrolling. The useful thing to notice about BazQux specifically is that almost nothing it charges for is RSS. Following a Telegram channel or a Facebook page is scraping a platform that publishes no feed and would prefer you did not. Pulling the comment thread under an article is a separate adapter per comment system. Turning a two-sentence summary feed into full text is a content extractor that gets worse every time a site adds a paywall. Those are the $30, and they are not a weekend — they are a fleet of small scrapers that break independently and forever. Build the reader, keep the extras as a wishlist, and if you do build the image proxy, do not leave it open.
What actually breaks
not "if". the specific failures.
- The scrapers, not the reader: a Telegram or Facebook page has no feed, so following one means parsing a page that changes without warning and is actively hostile to being parsed
- Comment fetching, which is a separate adapter for every comment system — Disqus, native WordPress, whatever a site rolled itself — each of which breaks on its own schedule
- Full-text extraction, which works beautifully until a site JavaScript-renders its article body, and then "feed reader" quietly becomes "headless browser fleet"
- An image proxy left open, which is the one component here that can actually hurt you: an unauthenticated fetch-any-URL endpoint is an SSRF probe into your own network and free bandwidth for whoever finds it
- Feed HTML, which is arbitrary markup written by strangers and will eventually carry a script tag into whatever renders it
- GUID churn, where a site changes its id scheme and re-delivers four hundred old articles as unread at six in the morning
- Storage, quietly, because full article text across three hundred feeds over three years plus a search index over it is not a rounding error
Is that you?
the verdict is a default, not a law
- You send conditional requests and back off on 429, so three hundred small blogs are not paying for your polling
- Your OPML export works before your themes do
- It reads feeds and stops there — no social scraping, no comment threads
- Feed content is sanitised before anything renders it
- You are running an image or content proxy that anyone on the internet can call with any URL
- Your poller has no ETag, no If-Modified-Since and no contact address in its User-Agent
- You are planning to follow social platforms and expect that to keep working
- Other people's subscriptions live in it and you are the only one who can restart it
If you build it anyway
the checklist, then the prompt that enforces it
- Send If-Modified-Since and If-None-Match on every poll, honour 304, and back off exponentially on 429 and 5xx. Put a real contact URL in your User-Agent so a publisher can email you instead of blocking you.
- Scale the poll interval to how often the feed actually publishes. A blog that posts monthly does not need checking every five minutes for the rest of the decade.
- Sanitise feed HTML through an allowlist before storage, not at render time. Strip script, iframe, event handlers and javascript: URLs, and assume every feed is hostile.
- If you build an image proxy, require your own session, sign the URLs, resolve and reject private IP ranges, cap size and content type, and never follow redirects blindly. An open proxy is the only genuinely dangerous thing in this project.
- Write OPML import and export first. It is thirty lines, it is the reason this category is safe to build, and it stops being possible to add once your schema has drifted.
- Deduplicate on a hash of link plus title as well as on guid, because the guid is the field feeds change without telling you.
- Decide your retention policy before you store full article text, or find out about it from a disk-full alert eighteen months in.
- Leave social-platform scraping and comment fetching out of v1. They are the majority of the maintenance and none of the value on day one.
I am building an RSS reader for myself. It is a crawler as much as an app, so build it in this order and push back if I ask for the fancy parts early. 1. Start with the fetcher's manners. Every poll sends If-Modified-Since and If-None-Match, honours 304 without re-parsing, backs off exponentially on 429 and 5xx, and identifies itself with a User-Agent containing a real contact URL. Write these before the UI exists. 2. Derive the poll interval from the feed's own publishing cadence, with a floor of fifteen minutes and a ceiling of a day. No global five-minute loop. 3. Then OPML import and export, with a round-trip test. This is the exit plan and it takes an hour on day one and never again. 4. Treat every feed as hostile input. Sanitise HTML through an allowlist at ingestion — no script, iframe, object, event-handler attributes or javascript: URLs — and store the sanitised form. Never render raw feed HTML. 5. Deduplicate on guid and on a hash of link plus title, so a feed that rewrites its ids does not resurrect two hundred read articles as unread. 6. Handle malformed XML, undeclared and lying encodings, and redirect chains that end at a parked domain, without crashing the whole poll cycle. One bad feed must not block the scheduler. 7. Do not build an image proxy in v1. If I ask for one later, require my session cookie, sign the URL, reject private and link-local IP ranges after DNS resolution, cap size and content-type, and refuse redirects to new hosts. Say out loud that an open proxy is the only part of this that can hurt me. 8. Do not build social-platform following or comment fetching. If I insist, tell me first that each is a per-site scraper with no stable contract, and that this is precisely what the $30 a year is buying. 9. Set a retention policy for stored article text before writing the storage layer, and make it a config value. 10. Out of scope: recommendations, ranking, sharing, mobile apps.
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 actually want is the comments, the social-page following or the full-text extraction, buy it — those are per-site scrapers somebody else keeps alive, and they are the entire $30. At two and a half dollars a month nobody is building this to save money anyway, so be honest about which half you want: the reader is yours for an evening, the scraper fleet is not.
$2.5/mo is cheaper than your weekend.
There barely is an exit problem, which is the whole reason this category is safe: your subscriptions are an OPML file and every reader on earth imports it. Write that export on day one and the worst outcome of abandoning your reader is an afternoon spent picking a new one. The only thing OPML does not carry is read state and stars, so if those matter to you, dump them as a CSV keyed on article URL alongside it.
Self-hosted RSS aggregator with multi-user support and a sane polling core.
Minimal self-hosted feed reader that already gets conditional requests and scraping rules right.
Questions
Why is this SHIP IT when almost everything else here is not?
Because RSS is a format published deliberately so that other people's code can read it, the data is your own reading list, the export standard is open and universal, and the worst realistic outcome is that you stop reading for a fortnight. There is no money, no strangers' data and no regulator anywhere near it.
What is the one thing that could actually go wrong?
An open image or content proxy. A reader that fetches arbitrary URLs on your behalf, with no authentication and no IP-range filtering, is an SSRF tool pointed at your own network and a free bandwidth service for anyone who notices. Either skip the proxy or lock it to your own session and refuse private address ranges.
Can I rebuild the comment-reading feature?
For one comment system, yes. For the general case, no — every site's comments live somewhere different, and BazQux's version is a maintained collection of adapters rather than a clever trick. This is the clearest example on the page of a feature that is cheap to buy and permanently expensive to own.
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.
RSS is a fetch loop with a read flag. The only real work is not being rude to the servers you're polling.
RSS is a solved format and a fetch loop. Reclaim your reading.
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