A free AI-powered tool that reviews your Y Combinator application before you submit it. Built by Lobster Capital, a VC fund 100% focused on YC companies with $40M+ deployed across 100+ YC startups.

Is YC Roaster really free?

Yes, completely free — no catch, no upsell. Lobster Capital built this to give back to the YC community and help more great companies get accepted.

How does YC Roaster work?

Upload your YC application (PDF or Word) and you'll receive AI-powered feedback shortly after submission, scored across 7 dimensions — including traction, team, market, and scalability. Applications that show strong potential get matched with a YC alumni reviewer for deeper, personalized feedback.

What kind of feedback will I get?

A scored evaluation across 7 dimensions with specific strengths, risks, and suggestions tailored to your application. It's not generic advice — the feedback is based on what's actually in your application.

Who built YC Roaster and why?

YC Roaster is built by Lobster Capital, a venture firm 100% focused on investing in YC companies. With 100+ YC companies in their portfolio, this is their way of helping more founders put their best application forward. Not affiliated with Y Combinator.

How is this different from asking ChatGPT to review my application?

YC Roaster is built by a team that invests exclusively in YC companies. The AI uses a purpose-built framework across 7 specific dimensions based on insights from reviewing hundreds of YC applications. Strong applications also get matched with real YC alumni reviewers — something no general-purpose AI can offer.

When should I submit my application?

As early as possible. The sooner you submit, the more time you have to get feedback, iterate, and strengthen your application before the YC deadline.

Will everyone get a Zoom call?

Everyone gets AI-powered written feedback. If you're matched with a YC alumni reviewer and they see strong potential, they may invite you for a 1-on-1 Zoom session.

Mozilla Just Opposed Chrome's Prompt API. What YC F26 Applicants Building Browser-Native AI Need to Know

On May 24, Mozilla formally marked its position on Chrome's Prompt API as "negative" on the official standards-positions tracker. The Prompt API lets web pages call a browser-bundled language model (today, Gemini Nano in Chrome; Phi-4-mini in Edge) directly from JavaScript, with no server round trip and no API key. It is the foundation a lot of YC F26 AI applicants are quietly betting on, and now the second-largest browser vendor has said it will not ship a compatible version.

If you are applying to YC F26 with a product that relies on the Prompt API or any other browser-native AI surface (the Writing Assistance APIs, the Translator API, the Summarizer API, the experimental Prompt-in-extensions API), you have a platform risk problem you need to answer in your application and your interview. Here is how to think about it.

What did Mozilla actually say?

In issue #1213 of Mozilla's standards-positions repo, engineer Jake Archibald laid out three concrete objections.

Calcification around one model. When you write a system prompt, you tune it to the quirks of one model. If Chrome ships Gemini Nano and most users get a good result with prompts tuned for it, every other browser that ships a different model will look broken, even if its model is objectively smarter. Mozilla's argument is that the web will end up locked to whichever model Google chooses, the same way GMail once forced Firefox to copy WebKit border-image bugs.

Policy lock-in. Chrome's docs require you to "acknowledge" Google's Generative AI Prohibited Uses Policy before using the API. That policy is broader than law. It bans things like "facilitating misleading claims related to governmental or democratic processes," which means a developer building a comment-summarizer tool is exposed to Google's terms based on whatever users paste in.

Overstated developer demand. Chrome's "Intent to Ship" cited "strongly positive" web developer sentiment. The actual evidence was two GitHub upvotes, one tweet, a dead blog post, and a survey about extensions.

Mozilla's position closes with: "We continue to oppose this API."

Why does YC care about this for your F26 application?

Y Combinator has been pattern-matching platform risk hard in 2026. The OpenClaw incident two days ago (where Claude Code began refusing requests that mentioned a competing product) is one version of this story. Anthropic shipping Claude for Small Business in May was another. The throughline is the same question: what part of your product survives when the platform you depend on does something you did not anticipate?

Mozilla's opposition makes the Prompt API a textbook platform-risk case study. If you tell a YC partner "we use Chrome's built-in AI so our product is free to run at scale," the followup is now obvious. What happens to your business when Safari and Firefox never ship a compatible API? When Google updates Gemini Nano and breaks your prompts? When your users paste a political opinion into your summarizer and Google sends you a TOS-violation letter?

What should you do if your YC F26 product is built on Chrome's Prompt API?

You do not have to rip it out. You have to show YC you have thought past it.

Option 1: Treat it as a progressive enhancement, not a core dependency

The strongest framing is that Chrome's Prompt API is a free fast-path for users who happen to be on Chrome, and you fall back to a paid server-side model for everyone else. Several YC-backed apps shipping on-device AI features in recent batches use this hybrid pattern: best path on supported devices, server path everywhere else. In your YC application, write one sentence like: "Prompt API covers roughly 60% of our users today and saves us about $0.0X per session. Our unit economics work without it."

Option 2: Build for the bring-your-own-model future

Mozilla and another commenter in the standards thread both pointed at the same alternative: ship the model yourself via a web extension, or load it client-side via WebGPU and WebNN. Hugging Face's transformers.js, the WebLLM project, and MLC's WebLLM runtime all work today. Your YC pitch becomes "we run any open model the user already has on-device" rather than "we depend on Google to give us a model."

Option 3: Be the company that abstracts the mess

This is the most underrated angle. If three browsers ship three incompatible local-LLM APIs (Chrome's Prompt API with Gemini Nano, Edge's version with Phi-4-mini, Safari's eventual equivalent built on Apple Foundation Models), there is a real YC-scale company to be built that papers over them. Cross-platform abstraction layers historically produced winners (jQuery, Modernizr, Capacitor). Position your startup as "the Stripe for browser-native LLMs," not "an app on top of Chrome."

What if your interview is this week?

If you have an S26 interview on the calendar, you will get asked about platform risk and you should have a clean two-sentence answer. The template that has been working in 2026 interviews:

"Today we use [Prompt API or whichever] because it is the fastest path to a working product and ships value to users on day one. Our roadmap moves to a model-agnostic runtime by month four, and our unit economics already assume the paid fallback."

The partners are not looking for you to have solved platform risk perfectly. They are looking for evidence you see it.

How do you stress-test your application before you submit?

Founders applying to YC F26 use peer review and alumni feedback to catch these blind spots before partners see them. Reading a 500-word application that depends on Chrome's Prompt API and not noticing the Mozilla risk is exactly the kind of hole a YC alum will flag in thirty seconds. YC Roaster routes your draft to YC alumni reviewers who have been in the partner-room and can tell you which platform-risk answers a partner will push on and which they will let pass.

The takeaway

Mozilla just made the Prompt API a public platform-risk story. That is helpful for YC F26 applicants, because the question is now obvious enough that you can answer it in your application instead of being surprised in the interview. Anchor on user value, show you have a model-agnostic fallback, and treat browser-native AI APIs as a free accelerant rather than a foundation.

If your application or interview answer is built on the assumption that Chrome's Prompt API is the universal future, the Mozilla position #1213 from this week is the rebuttal a YC partner is now going to bring up. Move first.