The Great App Discovery Problem: Why We Need Better Tools to Find and Track AI-Generated Apps

The Explosion of Micro-Apps

Let's be honest: we're living through a productivity revolution. Thanks to AI-powered development tools, creating useful applications has never been easier. Simon Willison maintains a collection of over 80 personal tools. Matt Sephton shipped 20 macOS apps in a single day. Designers are building custom web tools for their workflows. Developers are creating specialized utilities that solve hyper-specific problems.

This is fantastic. But it's also created a chaos problem.

The Discovery and Sharing Crisis

Here's the frustrating part: these amazing tools are scattered everywhere and nowhere at the same time. They live on personal websites, in GitHub gists, on social media threads, buried in Lovable projects, hidden in Replit deployments, or trapped in someone's terminal history. Some disappear after a month. Some get quietly improved without any notification system. And if you want to follow a creator you like? Good luck keeping track of what they ship next.

The core questions we're struggling with:

• How do I discover new apps that match my specific interests and platforms?
• How do I subscribe to updates when a creator I trust releases something new?
• How do I get notified when tools I depend on receive improvements?
• How do I safely share my favorite discoveries with others?
• How do I organize my own collection of personal tools for easy access?

Sound familiar? It should. We solved these exact problems 20+ years ago.

Enter: RSS Thinking for the Modern Era

Remember RSS? That simple XML feed format that powered blog subscriptions? It's not flashy. It's not trendy. But it was genuinely elegant because it solved a fundamental problem: how do you let people subscribe to updates without building a centralized registry or relying on algorithmic feeds?

The original author points to what made RSS beautiful: it was an interoperability layer. The New York Times exposed RSS feeds. Flickr did. GitHub did. Your local blog did. Any newsreader could consume any of these feeds. Users curated their own discovery experience.

What if we applied that thinking to the explosion of AI-generated applications?

Imagine an RSS-like feed standard where:

Creators publish feeds when they release new tools or update existing ones. Simon Willison's tools page becomes a subscribable feed. Your Claude plugin collection exposes a feed. Lovable templates surface updates.

Platforms participate natively. Replit makes it easy to publish a feed for your creations. Glitch does the same. Vercel exposes update feeds for projects. It becomes as standard as having a GitHub repo.

Users aggregate selectively. Instead of visiting 30 different creator websites, you subscribe to a feed in a newsreader (or a custom app built exactly for this purpose). Each tool shows up with metadata, links, install buttons, and version history.

Discovery becomes social. Like the old del.icio.us days, you share your favorite tools and their feeds with communities. You follow other developers' recommendations. You tag and curate collections. A decentralized version of ProductHunt, minus the algorithm.

Why This Works for Vibe-Coded Apps

Traditional app distribution assumes formal releases. You ship v1.0, users install it, you push v2.0 six months later. Apps are major life events.

With AI-assisted development, that model breaks down. Shipping a tool now feels more like publishing a blog post—frequent, personal, and experimental. You knock out a utility on Tuesday. You improve it Wednesday. You share it Thursday. The rhythm is faster and more organic.

This is actually perfect for RSS thinking. Blogs worked because they embraced constant, iterative publishing. An RSS-like system would do the same for micro-apps—treating each new tool and update as a publishable event worthy of notification.

The Practical Benefits

For creators: You get a simple, open format for announcing your work without relying on any centralized platform. Your tools stay on your own infrastructure. You control the metadata. You're not dependent on a startup's goodwill or business model.

For users: You get a unified, customizable experience. No algorithmic feeds deciding what you should know about. No algorithm deciding that the tools you actually use are "no longer relevant." Just clean, chronological updates from creators you've chosen to follow.

For discoverability: Tools don't disappear into the void. They have a permanent address. Other developers can surface and recommend them. Communities can build around recommendations. New tools become findable through the same mechanisms that made blogs discoverable.

For safety: Unlike centralized app stores that can disappear or change policies, an open feed standard survives indefinitely. If you're concerned about malicious updates, you can implement verification. You can fork and modify feeds. You can build tools to monitor version history.

The Challenge: Where Do Apps Live?

Here's the honest part—RSS-for-apps doesn't solve every problem. Traditional RSS feeds are mostly about information. Apps need to live somewhere and be executable. You need install destinations: iOS, macOS, Android, browsers, the web, terminal environments.

This is harder than just publishing a feed. But it's not impossible. The feed could include installation instructions specific to each platform. It could link to pre-built binaries, Docker containers, or cloud deployments. It could point to source code that users can fork and customize.

The feed becomes the interface layer. The actual app lives wherever makes sense for that tool.

What Would This Look Like?

Think of a simple ATOM-like format that extends RSS with app-specific metadata:

• Tool name, description, and creator
• Links to source code and documentation
• Version history and changelog
• Platform support (web, iOS, macOS, CLI, etc.)
• Installation method for each platform
• Tags and categorization
• Verification signatures (optional)

Every creator with a tools page publishes one. Every AI app platform makes it easy to generate one. Newsreaders and specialized apps consume these feeds and make discovery effortless.

The Beautiful Part

This isn't a platform. It's not a company. It's not even particularly complicated. It's a protocol—something anyone can implement, extend, or ignore as they see fit.

The open web ran on protocols like this. Email, HTTP, FTP, RSS. These weren't controlled by any single entity. They thrived because they solved real problems and anyone could build on top of them.

We lost something when we moved toward centralized platforms and app stores. Not everything, obviously—curation matters, and platforms do provide real value. But we lost some of the permissionless innovation and openness that made the early web magical.

What Happens Next?

This is where the community comes in. If you're building AI tools, consider how you'd share updates about them. If you're running a platform, think about what simple feed format would help your users discover and subscribe to new creations.

The infrastructure doesn't need to be revolutionary. It just needs to be useful and open.

The old internet had it right. Maybe it's time we borrowed from that playbook.