Why I Built Yet Another RSS Reader
I’ve been reading RSS feeds since Google Reader was alive. When Google shut it down in 2013, the community scattered. Some people moved to Twitter. Some moved to newsletters. Some — the stubborn ones — kept using RSS through a sequence of alternatives, each one a little worse than the last.
I’m one of those stubborn people. And after years of living with the compromises, I decided to build something myself.
This is the first post on this blog. It’s about why SlashFeed exists.
The Problem With Every Reader Out There
After years of trying alternatives, I kept hitting the same three walls — in different combinations, but always at least one of them.
The paywall trap
The polished, well-funded readers follow a predictable pattern. A free tier that is deliberately limited in ways that make the product frustrating to actually use — capped feed counts, no full-text search, no filtering, no keyboard shortcuts. Then a paid tier at a price that would be reasonable for, say, a project management tool, but feels steep for something whose core job is to show you a list of articles.
I don’t begrudge software being paid. Sustainable products need revenue. What I object to is the pattern of holding basic functionality hostage to justify a subscription. Keyword muting isn’t a pro feature. Full-text search isn’t a pro feature. These are table stakes for managing a real reading workflow.
The “just a reader” philosophy
On the opposite end: the tools that take pride in doing the absolute minimum. No reading statistics. No feed suggestions. No discoverability. No personality. Just a list of unread items and a mark-as-read button.
I respect the philosophy. Scope discipline is a virtue. But “just a reader” often means “we stopped where it got interesting.” The things that make reading sustainable at scale — understanding your own habits, finding new sources, managing a feed that’s grown past 50 subscriptions — get left out.
Infrastructure masquerading as an app
Then there are the self-hosted options that are technically capable but feel like assembling a server rack. Manual database setup, config files, a web server to put in front of it, and a UI that hasn’t been touched since the mid-2010s. The functionality is there if you dig for it. But an app you have to fight to install is an app you won’t open every morning.
I wanted something that was genuinely enjoyable to use — not just a backend with a stylesheet on top.
The AI Problem
Every RSS reader with money behind it is pivoting to AI right now. I understand why. AI features are the easiest way to justify a subscription tier, and they’re genuinely novel in a product category that hadn’t changed much in a decade.
But the AI integrations I’ve seen fall into one of two failure modes.
Invasive AI: the reader automatically injects AI summaries between every article, trains itself on your reading habits, builds “intelligence layers” you didn’t ask for. Every scroll through your feed has been preprocessed, categorised, and ranked by a model you can’t inspect. The feed becomes a curated experience instead of a direct channel. You’re no longer reading feeds — you’re reading what the AI decided you should read.
This is the same problem as algorithmic social media, just rebranded.
Useless AI: the reader adds an “Ask AI” button that, when clicked, calls an LLM API and returns a generic summary of the article you were already reading. It’s a demo feature. It answers the question “do we have AI?” without asking “does this help anyone?”
The design principle I’m working toward is simpler: AI should be on-demand and explicit, not automatic and ambient. You ask for a summary when you want one. You ask for key points when you’re short on time. The AI doesn’t have opinions about which articles you should see or in what order. Your subscription list is your subscription list.
What “Boring” Actually Means
The name is a deliberate provocation. Boring things work. Boring things don’t demand attention. Boring things sit in the background and do their job without requiring you to manage them.
The natural way to consume news — the boring way — is:
- You follow sources you trust
- New articles appear when they’re published
- You read what interests you
- You skip what doesn’t
- You mark things for later
That’s it. No engagement score. No “top stories for you.” No notifications nudging you back when you haven’t opened the app in a while. No algorithm trying to keep you in the feed longer.
The whole point of RSS is that it doesn’t optimise for your attention. It’s a dumb pipe from the publisher to you, and that’s the feature.
SlashFeed wants to be the most useful implementation of that dumb pipe. Good reading statistics so you understand your own habits. Feed discovery so you can find new sources. Newsletter inboxes so email-based writers become RSS feeds. A clean reader view. Categories. Search. The things you need to actually manage information at scale without the manipulation layer on top.
What’s Next: Building This in Public
Starting now, I’m documenting the development of SlashFeed step by step. Not open-sourcing the code (yet), but showing the process: the problems I’m solving, the design decisions, the trade-offs, and occasionally the things that went wrong.
The plan:
The next few months are about building an audience before there’s a product to sell. That means publishing technical posts about specific problems — how the feed parsing pipeline works with RabbitMQ and Broadway, how I built newsletter inboxes into the feed model, how the Tailscale binding works for private-network self-hosting. These are genuinely interesting engineering problems, and I’ll write them up whether or not you care about RSS readers.
I’ll also be writing about the product side: what I’m building next, why I’m prioritising it, what I decided not to build and why. The feature backlog for RSS readers is enormous once you start comparing against what’s out there. The job is deciding which parts of it are worth building for a self-hosted, privacy-first tool with a different set of values.
A few months in, I’ll open an early access list for people who want to try the app before public launch. If you’re in the Elixir community, work in journalism or research (professional RSS users), or just care about owning your information infrastructure — that list is for you.
At launch, I’ll do the obvious things: a Show HN post with actual technical depth, a Product Hunt launch, a post on the Elixir Forum. The self-hosted community on Reddit. The kind of launch that’s worth reading even if you don’t end up using the product.
If you want to follow along, there are two ways:
-
Subscribe via RSS (naturally) — the feed is at
/blog/feed.xml. You can also pastehttps://slashfeed.app/blog/feed.xmlinto any feed reader and it’ll find it automatically. - Follow on socials — I’ll be posting development updates and short threads about what I’m working on.
I’m building this because I want it to exist. The build-in-public part is how I stay honest about whether I’m building something useful or just scratching my own itch.
Thanks for reading.
— Luca