HomeThe rubric
How we review
Every answer, and your team if you describe it, is scored from 1 (needs a rewrite) to 5 (ready) against the rubric below. Each note names the principle it applies, so you can check the source yourself and disagree.
| Principle | What we check | Source |
|---|---|---|
| Say what it is in the first sentence | Partners read a lot of applications in a day. Put the plain description first; skip “we are transforming…” and sweeping intros about how big the problem is. Test: after one sentence, how close is the reader to being able to reproduce what you’re building? | Paul Graham, “How to Apply to Y Combinator” (hosted by YC) |
| Use a known reference when it helps | “It’s like X, but for Y” is an efficient way to describe a project. It isn’t a sign that the idea is derivative. | Paul Graham, “How to Apply to Y Combinator” (hosted by YC) |
| Be specific; show magnitude | For founder achievements, one concrete example beats an adjective (“exceptionally dedicated”). What matters is how big the achievement is, not what type it is. Don’t list the startup itself as the achievement. | Paul Graham, “How to Apply to Y Combinator” (hosted by YC) |
| Show insight, not execution promises | “Better designed and easier to use” is not an insight. Say exactly what you’ll do differently, and how you’ll beat the incumbent’s advantages. | Paul Graham, “How to Apply to Y Combinator” (hosted by YC) |
| Name the obstacles and flaws yourself | If the reader spots a problem you didn’t mention, they’ll assume you haven’t thought of it. Disclosing flaws, with a theory of how you’ll get past them, reads better than hiding them. | Paul Graham, “How to Apply to Y Combinator” (hosted by YC) |
| Prove people want it | Numbers beat adjectives: users, revenue, growth, interviews, retention, pilots, and where the idea came from in your own experience. | Paul Graham, “How to Get Startup Ideas” |
| Make the ‘hacked a system’ answer count | PG called the question about hacking a non-computer system a wildcard that can earn a second look. Pick a real story with a clear result. | Paul Graham, “How to Apply to Y Combinator” (hosted by YC) |
| Cut every word you don’t need | Print it, take a red pen, cross out every unnecessary word, and make what’s left specific and matter-of-fact. | Paul Graham, “How to Apply to Y Combinator” (hosted by YC) |
Founders & team
If you fill in the optional founder section, your team gets its own score (1 to 5), its strengths, the red flags a partner would likely notice (for example a solo non-technical founder, part-time founders, or a cofounder you met last month), concrete ways to present your background better, and rewrites of the usual founder questions you can accept. Partners have said they look at the founders right after the idea (PG, Caldwell).
| Principle | What we check | Sources |
|---|---|---|
| Someone on the team can build it | YC’s FAQ says the founding team should have the skills to build the product themselves rather than outsource it, which for most businesses means a technical cofounder. YC partner Dalton Caldwell reads the team first, looking for technical excellence. | Y Combinator: FAQ Dalton Caldwell (YC partner), “How to get into Y Combinator”, as reported by TechCrunch |
| Founder-market fit | Past jobs, research or projects tied to this exact problem. Caldwell: if you’ve built related tools before or your prior job is related, “that’s great to see.” | Dalton Caldwell (YC partner), “How to get into Y Combinator”, as reported by TechCrunch Paul Graham, “How to Get Startup Ideas” |
| One impressive achievement per founder | PG calls this the most important question on the application. Magnitude matters more than type, a specific example beats a generic claim, and the startup itself doesn’t count. | Paul Graham, “How to Apply to Y Combinator” (hosted by YC) |
| Evidence of execution and speed | Things you actually built, shipped or did, with results. PG’s phrase for the founders who succeed is “relentlessly resourceful”; slowness in launching is one of his 18 mistakes. | Paul Graham, “A Word to the Resourceful” Paul Graham, “The 18 Mistakes That Kill Startups” |
| Cofounder history | PG lists friendship as a founder quality: the best teams have known each other a long time and work well together. Fights between founders are on his list of startup killers, so a relationship that’s brand new is a risk worth addressing head-on. | Paul Graham, “What We Look for in Founders” YC Startup Library: “Founder FAQ: How did you meet your co-founder?” |
| Commitment | PG: most founders of failed startups don’t quit their day jobs, and most founders of successful ones do. YC expects founders to work full-time on the company during the batch and after. | Paul Graham, “The 18 Mistakes That Kill Startups” Y Combinator: FAQ |
| Team shape | YC accepts solo founders but says one-person startups are tough (PG’s mistake #1). Non-technical founders usually need a technical cofounder. If that’s you, say how you’re covering it. | Y Combinator: FAQ YC Co-Founder Matching |
The team review never hides a red flag. The honest move is to state it plainly with your plan (for example “Founder B goes full-time on [date]”), which is also what PG advises for flaws in general.
What the AI is told
- Review against these principles only; don’t invent “insider” rules.
- Never add facts. If a rewrite needs a number or name you didn’t give, it writes a [placeholder] for you to fill in.
- Keep the 50-character description at 50 characters or fewer.
- Judge the team only from what you wrote about it; never assume credentials, schools or employers you didn’t mention.
- Be direct and specific; praise only what is actually working.
Limits
Feedback is generated by an AI model (OpenAI’s open-weight gpt-oss-120b, run on Cloudflare Workers AI) and can be wrong. It’s a second reader, not a prediction of any decision. We have no connection to Y Combinator or any accelerator, and nothing here is endorsed by them.
Sources
- Paul Graham, “How to Apply to Y Combinator” (hosted by YC). Matter-of-fact first sentences, the “how close is the reader to reproducing it” test, describing a project as a variant of something known, the founders’ impressive-achievement question (magnitude over type, specific over generic), insight beyond “easy to use”, disclosing obstacles and flaws, the non-computer-system “wildcard” question, and the red-pen rule.
- Y Combinator: Apply page. Current batch, on-time deadline and decision date.
- Y Combinator: FAQ. Investment terms, Early Decision, late applications; solo founders, non-technical founders needing a technical cofounder, and the full-time commitment.
- Y Combinator: Interview guide. What happens after the written application.
- Paul Graham, “How to Get Startup Ideas”. Evidence that real people want it; ideas that come from founders’ own experience.
- Dalton Caldwell, “How to Apply and Succeed at Y Combinator” (YC blog / Startup School). How YC admissions works, the founder video.
- Dropbox’s Summer 2007 application (published by YC). The example PG points applicants to.
- Y Combinator: Requests for Startups. Ideas YC has said it wants to fund.
- Paul Graham, “What We Look for in Founders”. Determination, flexibility, imagination, and founders who have known each other a long time and work well together.
- Paul Graham, “The 18 Mistakes That Kill Startups”. #1 single founder, #17 fights between founders, #18 a half-hearted effort (keeping day jobs), #8 slowness in launching.
- Paul Graham, “A Word to the Resourceful”. “Relentlessly resourceful” founders: evidence you get things done.
- Dalton Caldwell (YC partner), “How to get into Y Combinator”, as reported by TechCrunch. He reads the team first: technical excellence, founder/market fit, and why single founders have it harder.
- YC Startup Library: “How to Find a Technical Co-Founder”. For non-technical founders.
- YC Startup Library: “Founder FAQ: How did you meet your co-founder?”. Cofounder history.
- YC Co-Founder Matching. YC’s free tool for solo founders looking for a cofounder.
- YC Startup Library. Further reading.
- Startup School. Free course from YC.