Last year I did an audit of my inbox. 40+ changelog newsletters. Most going to a folder I opened maybe once a month.
I wasn't ignoring them because I didn't care. I was ignoring them because the signal-to-noise ratio was unbearable. Marketing updates mixed with release notes. Version bumps buried under "Why We're Excited About 2025" essays.
Meanwhile, I was using 47 dev tools daily. Frameworks, APIs, databases, CLI tools, libraries. Each with its own changelog strategy:
- Some had RSS feeds (the good ones)
- Some only posted to GitHub releases (if maintainers remembered)
- Some announced updates on Discord and nowhere else
- Some had changelog pages buried three clicks deep in their docs
- Some used Notion. In 2024.
The breaking point came when a library I depend on deprecated an auth method. I found out two weeks later - when my integration broke in production.
The deprecation notice existed. It was in a changelog entry I never saw because it was posted to their blog, not their GitHub, not their RSS, not their email list.
I mass-unsubscribed from everything that week.
Then I started building.
What I Built
https://recent.dev is a changelog aggregator. One feed for every tool in your stack.
You build a personal "stack" of the tools you actually use.
Recent.dev syncs their changelogs automatically. You get a unified, chronological feed of updates - no marketing fluff, no noise.
But the product itself isn't what I want to talk about here. I want to talk about how it handles notifications - because that's where this project got personal.
The Notification Problem (And Why I Cared)
I work at https://novu.co. We build notification infrastructure.
Every day I see how companies approach notifications: blast everyone, same message, same channel, same frequency. Then wonder why users tune out.
I wanted to prove that notifications can be different. That they can be valuable instead of annoying.
Recent.dev became my playground for that.
Three Principles I Built Around
- User-Controlled Preferences
Most notification systems treat preferences as an afterthought. A settings page with 47 toggles that no one visits. In Recent.dev, preferences are the core experience:
- You choose which tools to follow. Build your own stack, not a default list someone else decided.
- You choose your channels. In-app feed? Email? Both? Neither? Your call.
- You choose your frequency. Real-time, daily digest, weekly roundup.
This isn't revolutionary. But it's rare. Most products decide for you and hope you don't unsubscribe.
- Digests Over Pings
Here's the math: 47 tools × even 1 update per week = 47 interruptions.
No one wants that.
Recent.dev uses a digest engine. Instead of 47 separate notifications, you get one consolidated update:
Your Weekly Stack Digest
• Next.js 15.2 - New caching API
• Tailwind 4.1 - Container query support
• Prisma 6.0 - Breaking: New migration format
• ... and 12 more updates
Grouped. Organized. One interruption instead of dozens.
The digest engine handles:
- Aggregation: Collecting updates across your subscribed tools
- Grouping: Organizing by tool, category, or severity
- Timing: Delivering on your schedule, not the tools' schedules
- Prioritization: Surfacing breaking changes and deprecations
This is what I mean by value-driven notifications. You're not getting pinged because something happened. You're getting a summary because you asked for it, when you wanted it.
- Multi-Channel, One Experience
Different contexts need different channels:
- In-app feed: When you're actively checking for updates
- Email digest: When you want a weekly summary in your inbox
- Future: Slack, webhooks, whatever fits your workflow
The key is that it's the same content, delivered through your preferred channel. Not fragmented across three different notification systems with three different preferences pages.
The Scraping Rabbit Hole (Bonus Technical Section)
Building the aggregator meant scraping 100+ changelog sources. This was its own engineering problem.
Changelogs are published in wildly inconsistent formats. Some sites have RSS feeds (bless them). A rare few expose JSON APIs. Most are static HTML with varying degrees of structure. And then there are the React SPAs that render everything client-side, and the occasional Notion embed that makes you question your career choices.
I ended up building four extraction strategies:
- RSS parser — For the well-behaved sites
- JSON consumer — For the rare APIs
- CSS selector scraper — For consistent HTML structures, with auto-detection
- AI-powered extraction — For the truly chaotic cases (Firecrawl + OpenAI fallback)
Plus a circuit breaker pattern because when you're scraping 500 sites, something is always broken somewhere.
The selector auto-detection was particularly fun. The system analyzes a changelog page, identifies repeating patterns (entries, dates, titles), and suggests extraction configs. It's wrong sometimes. But it's right often enough to save hours of manual configuration.
What I Learned
Building Recent.dev reinforced something I already believed but hadn't proved:
Notifications are a UX problem, not a volume problem.
The issue was never that I had too many changelogs to track. The issue was that every tool demanded attention on its terms:
- Its channel (email vs GitHub vs Discord)
- Its frequency (whenever they felt like posting)
- Its format (marketing blog vs raw release notes)
When you flip that - let users set the terms - notifications become useful again.
That's the Novu philosophy. That's what Recent.dev demonstrates. And honestly, it's just how this stuff should work.
Try It
Recent.dev launched on Product Hunt today.
Product Hunt: https://www.producthunt.com/products/recent-dev
Live site: https://recent.dev
It's free. I built it for myself first. Now it's yours.
If you're drowning in changelog noise, give it a shot. And if you have thoughts on how notifications should work - I'm genuinely curious. Drop a comment.
Top comments (0)