Your on-call engineer gets a page at 3 AM. A core feature is broken. After an hour of frantic debugging, they find the cause: a third-party API you rely on just shipped a breaking change, unannounced. Worse, they changed their rate limits. The feature isn't just broken, it’s now 100x more expensive to run. This isn’t a hypothetical. This is the reality of building software in 2025. And its roots go back to the shutdown of a beloved, simple product over a decade ago.
A recent post on Hacker News revisited the story of how Google helped destroy the adoption of RSS feeds. The shutdown of Google Reader in 2013 is often framed as a nostalgic loss for tech enthusiasts. But it was more than that. It was a watershed moment that signaled the web’s definitive turn away from open, decentralized protocols and toward closed, centralized platforms. We’re all living with the architectural consequences of that shift, and it’s making our systems more brittle every day.
The High Cost of Rented Land
When Google Reader died, it left a vacuum. Users didn't just find a new RSS reader. They migrated to platforms like Twitter and Facebook for content discovery. As developers, we followed the users. We accepted a simple trade: in exchange for access to massive, built-in audiences, we would build on their platforms. We’d use their APIs to post content, pull user data, and power our applications.
For a while, the deal worked. But we forgot a key detail. We were building on rented land. The landlord can change the terms, raise the rent, or evict you at any time.
Look at the chaos surrounding the Twitter (now X) API over the past couple of years. What was once a relatively open platform for developers became a walled garden with exorbitant pricing and arbitrary rules. Entire businesses built around its ecosystem, like third-party clients and analytics tools, were wiped out overnight. Or consider Reddit's API pricing changes in 2023, which effectively killed off beloved apps like Apollo. The platform decided its data was more valuable than the community of developers building on it.
This is the price of centralization. You don't own your distribution. You don't own your relationship with the user. The platform does. And your entire feature set, maybe even your entire business, exists at the whim of their next quarterly earnings call.
APIs as Moats, Not Bridges
RSS, for all its perceived simplicity, was a bridge. It was built on XML, a universally understood standard. It defined a simple, stable specification for how a publisher could syndicate content. If you could generate a text file that followed a schema, you could participate. It looked something like this:
<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0">
<channel>
<title>VooStack Engineering Blog</title>
<link>https://voostack.com/blog</link>
<description>Insights for developers, architects, and CTOs.</description>
<item>
<title>Google Killed RSS. Is Your API Dependency Next?</title>
<link>https://voostack.com/blog/google-rss-api-dependency-risk</link>
<description>The death of RSS wasn't just about news feeds...</description>
<pubDate>Mon, 29 Jul 2024 10:00:00 GMT</pubDate>
<guid>https://voostack.com/blog/google-rss-api-dependency-risk</guid>
</item>
</channel>
</rss>
Simple. Predictable. Stable. The spec hasn't meaningfully changed in 20 years. You could write a parser for this in 2004 and it would still work today.
Now, compare that to building a modern content aggregator. You don't have one spec to follow. You have a dozen proprietary APIs to integrate.
- You need one integration for the X API, with its complex OAuth 2.0a authentication and tiered access levels.
- You need another for the LinkedIn API, which is notoriously difficult to get access to.
- You need one for Mastodon, which uses ActivityPub, a different standard altogether.
- You need one for every other platform, each with its own authentication flow, data format, rate limits, and terms of service.
Each of these integrations is a maintenance burden. It’s a potential point of failure. The engineering cost of this complexity is a hidden tax on every team. We spend countless hours writing and maintaining brittle glue code instead of building core features. These proprietary APIs aren't bridges. They are moats, designed to keep users and data locked inside the platform's walls.
What We Lost: Control, Ownership, and Predictability
The shift from open protocols to closed platforms took three critical things away from both users and developers.
1. Control
With RSS, users had absolute control over their information diet. They subscribed to what they wanted, and they saw every post in chronological order. Publishers had control over their content. It was delivered, unedited, to their subscribers.
Today, the algorithm is in control. Your content is shown to users based on an opaque engagement model designed to benefit the platform, not you or your reader. Your product’s post about a critical security update might get buried, while a meme goes viral. You’ve lost control of your own distribution channel.
2. Ownership
In the RSS world, a user’s subscription list was a simple file (an OPML file, to be exact). They owned it. They could export it from Google Reader and import it into Feedly or any other reader in minutes. The social graph was portable.
Today, your follower list on any major platform is the platform's asset, not yours. You can't export your thousands of followers from one platform and move them to another. You've spent years building an audience, but you don't own it. This is why products that facilitate direct communication are so vital. When you use a service like our own MailStack to build an email list, you are building an asset you truly own. Email is the spiritual successor to RSS: a decentralized, open protocol that gives you a direct line to your users, no algorithm included.
3. Predictability
An open standard like RSS is predictable. It's governed by a community or a standards body, and it changes slowly and deliberately. A corporate API roadmap, on the other hand, is a marketing document. The real roadmap is dictated by business priorities. A feature can be deprecated with 90 days' notice if it's no longer strategic. A pricing tier can be eliminated if it's not profitable enough.
This lack of predictability forces engineering teams into a defensive posture. You can't build a five-year plan on a foundation that might crack next quarter. At AgileStack, we often work with teams to identify and mitigate these kinds of architectural risks. And a surprising number of them trace back to a deep, unexamined dependency on a single, proprietary platform.
What This Means for Your Team
It’s not 2013. We can't undo the centralization of the web. But we can build more resilient systems by learning the lessons from the death of RSS. It's about being intentional with your dependencies and proactively managing platform risk.
Here’s a practical starting point:
- Audit your platform risk. Make a spreadsheet. List every single third-party API your application depends on for a core function. For each one, ask: What happens if this API doubles in price tomorrow? What if it shuts down with 30 days' notice? What if they revoke our key? If the answer is "our business goes under," you have a critical vulnerability.
- Invest in owned channels. Your goal should be to convert transient followers on rented platforms into a durable audience you own. The most powerful way to do this is with an email list. Email is an open protocol. It's reliable. It's unmediated. Build features that encourage users to sign up. Use a reliable transactional email service to ensure you can always reach them.
- Favor services with open standards. When evaluating a new PaaS, SaaS, or developer tool, check for its commitment to open standards. Do they offer a simple, standard way to export your data? Do they integrate using standards like Webhooks, OAuth, or SAML instead of a completely proprietary SDK? Choosing tools that play well with others reduces lock-in.
- Provide your own RSS feeds. Yes, really. For your blog, your product updates, your status page, offer an RSS feed. It’s a trivial amount of engineering work. It signals to your most technical users that you respect their time and their control over their own tools. It's a small but powerful act of resilience against the closed web.
The convenience of building on centralized platforms is a powerful temptation. It's a short-term loan that can accelerate your initial growth. But the interest on that loan is your own resilience. The death of RSS was the first major invoice that came due. The next one could have your API key on it.
Building something in this space? AgileStack helps teams ship enterprise-grade software without the consulting-firm overhead. Book a 30-minute call and tell us what you're working on.