Should I vibe code
Build a native feed and read-later client with local search and sync through a chosen account
Ten dollars a year buys the native app. The part you can write yourself is not the part you were paying for.
?
Their verdict, the Reeder subscription (in-app) 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
Ten dollars a year. Start there, because it reframes what the question even is: nobody builds a feed reader to save money at that price. You build one because it is yours, and that is a perfectly good reason — a fetch loop, a parser, a table of entries and a reading view is an honest evening's work, it puts your subscriptions in a file you control, and it will outlive several of the hosted readers listed on this site. Ship it. Just be clear about which half you built. Reeder is not a reading service; it is a native client, and what a dollar a month actually pays for is the offline cache, the background refresh the operating system grants grudgingly, timeline position that is already correct when you pick up the iPad, and typography somebody sweated over. None of that is in your evening. And the sharpest fact in this entry is that if the native app is what you want, NetNewsWire is free, open source, and has been shipping for twenty years.
What actually breaks
not "if". the specific failures.
- Read state across devices, which is the only genuinely hard problem in a reader and the reason Reeder makes you pick an account to sync through in the first place
- The offline cache, on the day you open the app on a plane and discover it cached the text but hotlinked every image
- Background refresh, which on a phone is a privilege the OS grants and withdraws based on how you use the app, not on what your code asks for
- The unified timeline, once you add YouTube, podcasts and a social feed — that is four more source types with four auth stories and four rate limits, and none of them are RSS
- Truncated feeds, where half your subscriptions ship two sentences and a link, and full-text extraction stops being optional
- Typography, which is the actual product and is never finished: dynamic type, dark mode, hyphenation, code blocks, and a table from a 2004 blog post
Is that you?
the verdict is a default, not a law
- You read on one machine, and a terminal or web reader is honestly what you want
- The subscription list lives in an OPML file you can hand to anything else tomorrow
- You want a filter or a grouping no shipping reader offers, and everything else is negotiable
- The requirement is really "a beautiful native iOS app that is already synced when I open it", because that is months of Swift and a sync design, not an evening
- You are going to poll aggressively from a home IP and then wonder why a publisher's CDN stopped answering
- Losing read state across three devices would annoy you more than the ten dollars ever did
If you build it anyway
the checklist, then the prompt that enforces it
- Write the OPML export before the reading view. It is an hour, it is a twenty-year-old standard, and it makes the entire project reversible.
- Pick one place read state lives — a synced database, a plain file, an existing account — and never let two devices both think they own it.
- Cache article bodies and images at fetch time if offline reading is a goal. A cache full of links to other people's servers is not a cache.
- Store entry identity as guid when present and a stable hash of link plus title otherwise, so a feed rewriting its ids does not resurrect two hundred read articles.
- Keep non-RSS sources behind the same internal interface as feeds, so YouTube or Mastodon support is an adapter and not a second application.
- Set a retention policy up front. Full text from a hundred feeds for five years is a real database, and search over it is a real index.
I am building a personal feed reader as a client — the reading experience is the point, not the crawling. Build it in this order and push back if I ask for surface before substance. 1. OPML import and export first, both directions, round-tripping cleanly. That is my exit path and it takes an hour. 2. Then decide, out loud, where read state lives, and write that decision into the README. One owner: a synced file, a synced database, or an existing sync account. Never two devices both writing an authoritative value. 3. Model entry identity explicitly — guid if the feed provides one, otherwise a stable hash of link plus title. Add a test where a feed rewrites all its guids and assert nothing becomes unread again. 4. Use a maintained feed parser. Do not hand-roll XML. Assume Atom, RSS 2.0, JSON Feed and undeclared encodings all appear in the same subscription list. 5. If offline reading matters, fetch and store images and article bodies at capture time, and show me what a hundred feeds for a year costs in disk before I commit to it. 6. Put non-RSS sources behind one adapter interface. YouTube, podcasts and social timelines are separate adapters or they are not in scope — do not thread platform-specific code through the reader. 7. Set retention and search up front: how long full text is kept, what is indexed, and what a query costs at ten thousand entries. 8. Do not build accounts, sharing or a hosted service. This is one person's reader. If I ask to host it for friends, tell me I have just taken on other people's reading history and an uptime expectation. 9. Out of scope, and say so rather than half-building it: a native mobile app, background refresh, and cross-device sync of scroll position. If I insist I want those, tell me NetNewsWire is free and open source and Reeder is ten dollars a year, and ask what my evening is worth.
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
Only for the app, not the reading. A dollar a month is what shared feeds, the social and video timelines and someone else's typography cost, and at that price the argument for building is never financial. The stronger move if you want a real native client is NetNewsWire: free, open source, actively released, and better than what you would ship. Build your own when the thing you want is a filter, a digest or a layout nobody sells.
$1/mo is cheaper than your weekend.
OPML out, and you are done — every reader on earth imports it. Read state is the only thing that does not travel, and after a week you will not miss it.
Free, open-source native Mac and iOS feed reader that is actively released and directly replaces what the subscription buys.
Mature open-source RSS reader with feeds, filters, and self-hosting support.
Minimalist self-hosted feed reader in Go, small enough to read the whole codebase in an afternoon.
Questions
A dollar a month is nothing. Why is this SHIP IT and not "just buy it"?
Because the verdict measures regret, not price. Building a reader risks nothing — no stranger's data, no money, no uptime anyone else depends on — and the version you write is genuinely yours. Buying it is also correct. Those two things are allowed to be true at once, and the entry that pretends otherwise is being dramatic for effect.
What is actually hard about a feed reader?
Read state across devices, and nothing else comes close. Everything upstream of it — fetch, parse, store, render — is well-trodden. Sync is where every reader project quietly stops, which is exactly why Reeder syncs through an account you already have rather than running its own backend.
Do I have to worry about being a badly behaved crawler?
Yes, and the Inoreader entry covers that in detail because it is the same lesson. Short version: conditional requests, honour 304 and Retry-After, back off on errors, put a contact URL in your User-Agent, and poll hourly rather than every minute.
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-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice