All posts
Guides

Why I Built My Own RSS Reader

N
Nick VogelAugust 1, 2026 · 4 min read
Subscribe

I decided years ago that there had to be a better way to use an RSS reader. I've tried many over the years, and none gave me a way to act on anything I'd read. I would read something, mark it as read, and move on.

RSS is still a great way to stay informed on the topics you care about without visiting a bunch of sites. But reading without action leaves a lot on the table. I wanted a reader where I could read stories from sources I trust and then do something about them. Nobody built that, so I did.

Where the other readers lost me

Feedly came closest to what I wanted, and I used it for free for years. Even so, it falls short, with a sometimes clunky UI and a mess of feed management. For a long while my complaint was that it didn't accept webp images. Now I don't think a feed reader needs images at all. I'm not in there for media or clickbait thumbnails. I want the meat and I want out.

And to be fair to Feedly: it was reliable the whole time I used it. Fear of the service dying was never my reason for building. Building bought me something else. Since I made Riverbed and use it every day, I know it isn't going anywhere, and I know I can make it better each day.

My thoughts belong to me

Most feed readers make it hard to export your reading and your learning in any meaningful way. If my notes and thoughts are trapped in an app, they don't do much for me. My thoughts belong to me, and they should end up wherever they benefit me most.

For me that's a markdown directory I call my second brain. Everything I've read and learned lands there as plain files, sorted so that both I and my AI assistant can work with it. That's the ownership that means something to me. Not a data-export button buried in settings, but my reading landing, automatically, in files I control.

What Riverbed refuses to do

I don't plan on putting ads in the feed. Algorithmic serving is off the table too. I don't want to be another place that pulls readers into an endless scroll just for ad revenue. And as much as I can help it, outside of rendering what a feed itself contains, I don't use images. The point is the reading.

Riverbed also has a triage mode, for when you're reading for information with intent. Nothing gets marked as read unless you deem it so. And if you want to save an article, you have to say why. There are no lazy saves here.

All of this has a cost. If you want a pretty, magazine-style reader full of images, or an app that guesses what you'll like, Riverbed will feel spartan. That's by design, and it's not for everyone.

The unread count

When an unread count gets too high, it gives me anxiety. So Riverbed handles it two ways. When you add a new feed, you choose how many posts to bring in, instead of inheriting a thousand-item backlog. And there's a river mode that marks items as read as you scroll, so you can catch the headlines and the first couple of sentences, decide whether to click in, and never think about marking anything.

Who shouldn't use it

If you just want to mark things as read, or move articles into a read-later tab you'll never open again, you don't need Riverbed. Feedly or any of the established readers will serve you fine. Riverbed is for people who want their learning stored somewhere external, in their own vault or a hosted directory through Riverbed, where they'll actually use it later.

If Riverbed disappeared tomorrow

If Riverbed disappeared tomorrow, my feeds would survive. My future learning would wither.

That's the idea in two sentences. Saving an article with the reason I saved it, and having that flow from an outbox directly into my second brain on a schedule, means I never forget about a great post again. The reading was never the hard part. Keeping what the reading taught you is, and that's the problem I built Riverbed to solve.

New posts land in the feed first. Subscribe.
Join the waitlist