YC RFS Developer Tools — Specific Opportunities YC Wants Founders to Build

YC's developer tools RFS has shifted significantly from the 2020-2023 era when "developer tools" primarily meant observability, CI/CD improvements, and database infrastructure. The current thesis is anchored around one central premise: AI agents are changing who writes software, what software gets written, and how that software gets deployed and maintained. Every developer tools opportunity YC is currently most excited about connects to this shift.

The core question YC asks about any new developer tools company: does this product exist because AI has changed something fundamental about software development — or would it have been useful five years ago too? Products in the second category are still fundable, but they face a more skeptical reception than products that are genuinely new because of the AI transition.

1. A Cloud for Small Software

What YC specifically wants: YC partner Pete Koomen has named this explicitly in the Fall 2026 RFS. AI agents can now build bespoke, single-purpose software tools for individuals and small teams in minutes. The problem is that this "small software" — tools built for one person, one team, one workflow — is still hard to deploy, share, and manage. Incumbent clouds (AWS, GCP, Azure) were designed for "big software" that scales to millions of users, at the cost of enormous complexity that small software does not need.

The opportunity: A cloud platform designed specifically for small software — one that makes deploying and sharing an AI-generated tool as easy as sharing a Google Doc. Core technical challenges include auth and permissions without engineering overhead, security for arbitrary user-generated code, and customization at the team level.

What a fundable application looks like: A working product that lets a non-engineer deploy and share a working tool built by an AI agent in under 5 minutes, with real users already doing this regularly. Retention data showing users return to the platform to build more tools — not just deploy once and forget.

2. Self-Maintaining APIs

What YC specifically wants: YC partner Harsha Gaddipati named this in the Fall 2026 RFS. Over 30% of AWS service downtime has been attributed to external API or package changes going unnoticed. Breaking changes ship with little warning. Useful features launch and go unnoticed. Changelogs do not get read. With agentic coding tools now having standard codebase access, the infrastructure for automated code changes exists — what is missing is the application layer connecting API providers to their customers' codebases.

The opportunity: When Stripe ships a breaking change, an agent should scan customer codebases, identify affected usages, and open a PR with the fix automatically. This could work as per-provider agents ("Install Stripe's update agent") or as a neutral third-party service tracking changes across vendors — like Dependabot but for APIs.

What a fundable application looks like: A working integration with at least one major API provider (Stripe, Twilio, Plaid) that has successfully detected a real API change and opened a correct automated PR in at least one customer codebase. Developer adoption evidence — GitHub stars, paying customers, or a waitlist with credible signal from engineering teams at real companies.

3. Multiplayer AI

What YC specifically wants: YC partner Aaron Epstein named this in the Fall 2026 RFS. The best work tools of the last two decades won by going multiplayer — Google Docs beat Word, Figma beat Photoshop. But AI has not had its multiplayer moment. Working with AI agents is still single-player: one person, one chat, one private context. As agents run tasks that take hours or days, teams need to drop in, redirect, and hand off shared agent sessions — the way they would work with any other team member.

The opportunity: Shared, live, multiplayer agent sessions for engineering teams coding together, sales teams working a deal, support teams resolving a ticket. The infrastructure problem: turning the work a team does with AI from a thousand private threads into a shared, living context that any authorized team member can join and redirect.

What a fundable application looks like: A working product where two or more people can join the same live agent session, see what the agent is doing, and redirect it in real time. Retention showing teams return to collaborative sessions rather than reverting to solo AI use. At least one enterprise team using it for a real multi-day project.

4. Devtools for AI Agents (from the 2025 RFS)

What YC specifically wants: As AI agents are deployed in production, the tools for managing, deploying, monitoring, and debugging them lag significantly behind the tools available for traditional software. YC has explicitly named "devtools for AI agents" across multiple recent RFS editions — covering agent orchestration, evaluation frameworks, cost management, and reliability tooling.

The opportunity: The same category that DevOps and observability tooling addressed for traditional software needs to be rebuilt for agentic systems. What does debugging look like when the "bug" is an agent making a wrong decision? What does monitoring look like when you are tracking task completion rates and human override frequency rather than error rates and latency?

What a fundable application looks like: A product being used in production by at least 3-5 companies running real AI agents, with measurable improvements in agent reliability or cost efficiency that the product's users can cite specifically.

5. B2A — Software Where the Customers Will Be Agents

What YC specifically wants: A category named explicitly in recent YC RFS editions. As AI agents become the primary interface for completing tasks — booking travel, managing procurement, executing research — a new class of software will be designed with agents as the primary customer rather than humans. APIs structured for agent consumption, workflows optimized for LLM reasoning rather than human navigation, and pricing models built around agent-scale usage.

The opportunity: Every existing SaaS product will need a B2A layer. New products can be built B2A-native from day one — with no UI, no human-friendly onboarding, no support documentation, just a clean API and a machine-readable capability description. This is a fundamentally new product architecture challenge.

What a fundable application looks like: A product with at least 5 paying customers who are AI agent systems (not humans using agents) — customers whose primary interaction with your product is programmatic, at scale, without human intervention. Usage metrics showing agent-driven API calls at volumes that no human-operated SaaS product would produce.

Looking at developer tools companies funded in recent batches (W24, S24, W25), the patterns in what gets funded versus what gets rejected reveal the practical application of the RFS thesis:

Funded consistently:

• LLM observability and evaluation (Braintrust, Helicone, Portkey, Langtrace) — all addressing the monitoring gap for AI production systems
• Agent infrastructure (Composio, Recall.ai) — addressing the tooling layer for agent deployment
• Serverless infrastructure for AI workloads (Modal) — addressing compute infrastructure shaped by AI training and inference demand

Less funded in recent batches:

• Traditional SaaS developer tools without an AI-native angle
• API wrappers without proprietary data or workflow integration
• Observability tools for traditional (non-AI) software systems, given the crowded existing market

The acceptance pattern: Developer tools companies that get into YC in 2025-2026 almost universally have one thing the RFS explicitly named — they are solving a problem that exists specifically because AI agents are becoming a new class of software actor, not a problem that has existed for years and is now being solved with AI.

Developer tools have been consistently strong in YC portfolios across multiple cycles for a structural reason: developers are the primary buying decision-makers at their companies for the tools they use, which compresses the sales cycle and allows product-led growth to work. A developer who finds a tool useful will use it personally, recommend it to their team, and advocate for paying for it internally — all without a formal enterprise sales process.

This buyer profile makes developer tools companies disproportionately capital-efficient at early stages relative to enterprise SaaS companies selling to procurement committees. YC values this efficiency. A developer tools company with 5,000 daily active developers and $50K MRR is often more fundable at YC than an enterprise SaaS company with 3 customers and $80K MRR — because the developer tools company has a demonstrated organic adoption engine that the enterprise company does not.

The AI transition has added a second reason for YC's sustained interest: developer tools companies sit at the center of the AI adoption wave. Every company adopting AI needs tooling for the adoption — and developer tools founders are uniquely positioned to build that tooling because they are, themselves, developers experiencing the transition from the inside.