We Need RSS for Sharing Abundant Vibe-Coded Apps

The Discovery Problem Nobody's Talking About

We're drowning in apps that didn't exist five minutes ago.

Every day, thousands of people describe what they want to an AI, and minutes later, they have a functioning application. No GitHub repo. No App Store submission. No landing page. Just a URL that works—until it doesn't, or until it's buried under tomorrow's creations.

This is the vibe-coded app revolution: applications conjured from natural language, deployed instantly, and shared haphazardly through screenshots on Twitter or links in Discord channels that scroll away forever. We've solved the creation problem so thoroughly that we've created a distribution crisis.

The irony isn't lost on me. We have more tools than ever to build products, yet we're regressing to pre-web discovery patterns—word of mouth, manual curation, algorithmic feeds that bury signal in noise. We need infrastructure that matches the abundance we've created.

We need RSS for vibe-coded apps.

Why Vibe-Coded Apps Break Traditional Distribution

Traditional software distribution assumes scarcity and permanence. You build an app over months, launch it ceremonially, submit it to directories, optimize your SEO, and maintain it indefinitely. The entire infrastructure—from Product Hunt to the App Store—is built around these assumptions.

Vibe-coded apps obliterate this model.

These applications are abundant rather than scarce. When creation takes minutes instead of months, the volume explodes exponentially. A single person can generate dozens of micro-apps in an afternoon, each solving a specific problem or exploring a particular aesthetic.

They're ephemeral rather than permanent. Many vibe-coded apps are experiments, prototypes, or solutions to momentary needs. They might exist for a week, get forked into something else, or simply fade away when their creator loses interest. This isn't a bug—it's a feature of low-friction creation.

They're context-dependent rather than universal. A vibe-coded app might be perfect for a specific workflow, aesthetic preference, or use case that affects 200 people globally. Traditional distribution channels optimize for mass appeal. Vibe-coded apps thrive in niches.

And critically, they're socially discovered rather than algorithmically surfaced. The best vibe-coded apps spread through networks of builders sharing what they've made. But social platforms are terrible archives. A brilliant app shared last Tuesday might as well not exist by Friday.

The RSS Parallel: Solving Abundance Through Standards

RSS solved a similar problem two decades ago.

Before RSS, following multiple websites meant manually checking each one, bookmarking dozens of URLs, and inevitably missing updates. The web was abundant with content, but discovery was manual and exhausting.

RSS created a standard format for publishing updates, a decentralized distribution model that didn't depend on any single platform, and an user-controlled experience where readers decided what to follow rather than algorithms deciding what to show.

The parallel to vibe-coded apps is striking. We need:

• A standard format for describing and sharing applications
• A decentralized way to publish and discover these apps
• User control over what types of apps they want to see
• Persistence without requiring permanent maintenance

But we can't just copy RSS directly. Vibe-coded apps have unique requirements that 2004-era thinking doesn't address.

What an RSS for Apps Actually Needs

Machine-Readable App Metadata

The fundamental unit isn't a blog post—it's a functioning application. Our feed format needs to describe not just what an app does, but how to interact with it.

This means structured metadata about:

• Functionality: What does this app actually do? Not marketing copy, but parseable descriptions of inputs, outputs, and transformations.
• Interface patterns: Is this a chat interface? A form? A canvas? Knowing the interaction model helps users (and AI agents) understand how to engage.
• Dependencies: What APIs does it call? What models does it use? This transparency matters for trust and reproducibility.
• Vibes: Yes, seriously. The aesthetic, tone, and feel are first-class properties of vibe-coded apps. A feed format should capture whether something is "brutalist dashboard" or "soft pastel productivity tool."

Temporal Metadata and Decay Signals

Unlike blog posts that remain relevant indefinitely, vibe-coded apps have lifecycles. Our feed format should embrace this.

Apps should be able to signal their expected lifespan, their maintenance status, and whether they're experiments or production-ready tools. A "last verified working" timestamp tells consumers more than a publication date.

This also enables new discovery patterns. Imagine subscribing to "experimental apps from the last 48 hours" or "stable tools updated this month." The temporal dimension becomes a feature, not a bug.

Forkability and Provenance

Vibe-coded apps evolve through remixing. Someone sees an app, tweaks the prompt, and creates a variant. This is creation as conversation.

Our feed format should treat forking as a first-class concept. When App B is derived from App A, that relationship should be explicit and traversable. This creates a graph of applications rather than a flat list—more like Git than like RSS.

Provenance also matters for trust. Knowing that an app came from a builder you respect, or that it's been forked and improved by a community, provides social proof that traditional app stores struggle to capture.

Embedability and Preview

One of RSS's weaknesses was that feeds were purely textual. You had to click through to experience the content.

For vibe-coded apps, the feed itself should enable interaction. Imagine feed readers that can render live previews, allow you to test functionality inline, or even fork apps directly from your reader.

This requires standardized preview formats—perhaps WebAssembly bundles, iframe-able endpoints, or structured API descriptions that feed readers can interpret. The feed becomes a living catalog, not a static list.

The Infrastructure We Need to Build

Feed Publishers for AI Platforms

Every platform that enables vibe-coded app creation—Claude Artifacts, Replit Agent, v0, Lovable, Cursor—should publish feeds of public creations.

This doesn't require centralization. Each platform runs its own feed server, using a common format. Builders opt in to sharing, and consumers subscribe to the feeds they care about.

The key is platform-level support. Just as blogging platforms made RSS generation automatic, AI development platforms should make app feeds a default feature.

Aggregators and Curators

Raw feeds from platforms will be noisy. We need an ecosystem of aggregators that filter, curate, and recombine feeds based on different criteria.

Some aggregators might focus on specific domains: "data visualization tools from the last week" or "productivity apps with dark mode." Others might use AI to cluster similar apps, identify trending patterns, or surface hidden gems.

Crucially, these aggregators should also publish feeds. This creates a composable ecosystem where curation itself becomes a distributed activity.

Feed Readers That Understand Apps

We need new reader experiences designed for applications, not articles.

Imagine a feed reader where each item is an interactive preview. You can test the app, see its source, fork it with modifications, or save it to a personal collection. The reader becomes a workbench, not just a consumption tool.

These readers should also enable discovery through interaction. If you frequently engage with apps that process images, the reader learns to surface more image-processing tools. If you fork apps with specific UI patterns, it shows you similar patterns from other creators.

Persistent Archives

Ephemerality is fine, but valuable apps shouldn't disappear just because their creator moved on.

We need distributed archiving—services that crawl app feeds, preserve snapshots, and keep things running even when original deployments vanish. Think Internet Archive, but for vibe-coded applications.

This also enables temporal exploration. Want to see what people were building with AI tools in early 2025? The archive becomes a historical record of how we learned to work with these capabilities.

The Business Model Question

RSS struggled commercially because it disintermediated platforms. Feed readers couldn't inject ads, track users, or control distribution—which is why social media platforms killed it.

But the context is different now.

Vibe-coded apps aren't ad-supported content. They're tools, and tools have clearer monetization paths. A feed ecosystem could support:

• Premium feeds: Curated collections from expert builders, available by subscription
• Compute marketplaces: Apps in feeds that require backend processing could charge per-use
• Fork monetization: Original creators could receive micropayments when their apps are forked and used
• Platform services: Discovery, hosting, and archiving services that charge for infrastructure

The key is keeping the protocol open while enabling commercial services on top. RSS failed because platforms saw it as a threat. An app feed protocol succeeds by making platforms more valuable.

What This Enables That's Impossible Today

Ambient Discovery

Right now, finding vibe-coded apps requires active hunting. With feeds, discovery becomes ambient. You subscribe to builders you respect, topics you care about, or aesthetic vibes you enjoy, and relevant apps flow to you automatically.

This is how we make abundance manageable. Not by limiting creation, but by creating better pipes for distribution.

AI Agents as Consumers

A machine-readable feed format means AI agents can discover and use vibe-coded apps autonomously.

Imagine an AI assistant that subscribes to feeds of data processing tools, automatically evaluates new apps against your workflow requirements, and suggests integrations. The feed becomes infrastructure for AI-to-AI collaboration.

Compositional Innovation

When apps are easily discoverable and forkable, innovation becomes compositional. You build on what others have made, remixing and recombining rather than starting from scratch.

This is how open source created exponential value. A feed protocol for apps could do the same for vibe-coded creations.

Cultural Archaeology

Five years from now, researchers will want to understand how we learned to work with AI. A feed archive provides that record—not through formal publications, but through the actual artifacts we built.

This matters for AI safety, product design, and cultural history. The apps we make reveal how we think about these tools.

The Path Forward

We don't need permission to start building this.

The first step is defining a minimal spec—a JSON format that describes an app with enough structure for machines to parse and enough flexibility for creativity. This should be a community effort, not a corporate standard.

Second, we need early adopters among platforms. If even one major AI development tool starts publishing feeds, it proves the concept and creates pressure for others to follow.

Third, we need compelling reader experiences. Someone needs to build the feed reader that makes people say "I can't imagine discovering apps any other way." This is a product design challenge, not just a protocol problem.

And finally, we need archiving infrastructure. Even a simple service that crawls feeds and preserves snapshots would provide immense value.

The Abundance We Deserve

The promise of AI-assisted development was never just faster coding. It was democratizing creation—enabling anyone to build tools that match their needs, their aesthetics, their vibes.

We've achieved that creation abundance. Now we need distribution infrastructure that matches it.

RSS worked because it embraced the web's fundamental architecture: decentralized, open, user-controlled. An RSS for vibe-coded apps should embrace the same principles while addressing the unique properties of applications: their interactivity, their temporality, their forkability.

This isn't about recreating the past. It's about building infrastructure for a future where creation is so abundant that discovery becomes the bottleneck.

We solved creation. Now let's solve sharing.

The apps are out there, being built right now. We just need a way to find them.