Epismo
Get started

v1 Published snapshot

Y Combinator Application Playbook

A batch-agnostic, evidence-first English playbook for drafting, reviewing and defending a Y Combinator application. Suitable for idea, prototype, revenue and hardtech startups. Its goal is to reveal the founders' actual knowledge, execution and potential, not manufacture an impressive story.

PRINCIPLES: (1) Explain what you build, for whom and how it works before broad market vision. (2) Lead each answer with a direct response and support it with verifiable evidence. (3) Prefer clear nouns, active verbs, actual customer behavior and precise metrics to marketing adjectives. (4) Separate observed facts, hypotheses and future plans. (5) Show original insight that changes product or go-to-market decisions. (6) Use evidence appropriate to the startup's stage. (7) Keep application, founders, video, demo, metrics and interview consistent. (8) Never fabricate users, interviews, achievements or financial results.

YC has not published a formal scoring rubric. Review heuristics below are a synthesis, not YC admission rules. Question wording and submission requirements can change by batch. Historical applications are examples, not guaranteed formulas.

SELECTED PRIMARY REFERENCES:
Paul Graham, How to Apply: https://www.ycombinator.com/howtoapply.html
Michael Seibel, How to Pitch Your Company: https://www.ycombinator.com/blog/how-to-pitch-your-company/
Kevin Hale, Application Clarity / Evaluate Ideas Part 2: https://www.ycombinator.com/blog/startup-school-week-8-recap-adora-cheung-on-prioritizing-your-time-and-kevin-hale-on-evaluating-startup-ideas/
Kevin Hale & Eric Migicovsky, Evaluate Ideas / Talk to Users: https://www.ycombinator.com/blog/startup-school-week-1-recap-kevin-hale-and-eric-migicovsky/
YC, Application Video Instructions: https://www.ycombinator.com/video
Dropbox, Original YC Application: https://www.ycombinator.com/apply/dropbox
Paul Buchheit, DoorDash from Application to IPO: https://www.ycombinator.com/blog/doordash-from-application-to-ipo/
Jessica Livingston, Tips for YC Interviews: https://www.ycombinator.com/blog/tips-for-yc-interviews
Dalton Caldwell, How to Apply and Succeed at YC (Startup School): https://www.ycombinator.com/blog/startup-school-videos/
Sam Altman, Startup Playbook: https://www.ycombinator.com/blog/startup-playbook/

Back to playbook

Starting inputs

verifiedMetrics

string

founderBackgrounds

string

productDescription

string

actualCustomerEvidence

string

applicationFormQuestions

Optional exact questions from the active form.

string

companyName

string

startupStage

Idea, prototype, launched, revenue, growth, hardtech or other.

string

Steps

  1. 1

    Map questions and build an evidence ledger

    Read the current application form if available. Capture the exact prompt, word/character limits, owner, key claim, best supporting facts, missing evidence and draft status. Do not treat old application forms as current requirements. Organize by product, problem, why this idea, unique insight, founders, cofounder relations, technical ownership, progress, competitors, business model, market, finance, alternative ideas, video and demo.

    Build a single source-of-truth fact sheet and evidence ledger. Classify every material claim as FACT (verified), INFERENCE (reasoned from facts), HYPOTHESIS (untested), PLAN (not yet executed) or UNKNOWN. Record measurement windows, source, definitions and confidence. Flag high-risk claims requiring verification, especially user counts, revenue, patents, research results and personal achievements. If a fact cannot be substantiated, qualify or remove it. Never invent official YC requirements.

  2. 2

    Write a legible one-line company description

    Lead with what the product does rather than the market's importance. Template: "[Specific users] use [concrete product] to [perform main action] so they can [valuable outcome]." Distinguish what is already built from what is being built or merely planned. Remove abstract terms like revolutionary, ecosystem, next-generation, agentic platform, and disruption when they conceal the product's real function. Avoid technical acronyms unless essential. Explain the core use case in plain English.

    Create one sentence, then a two-sentence version. Apply Michael Seibel's Email Test: send only the two-sentence explanation to a smart outsider; ask them to paraphrase what the company builds, who uses it and how. If their paraphrase is wrong, rewrite. FICTIONAL EXAMPLE: Weak "AI-driven platform transforming financial operations." Better "We build software that matches supplier invoices to purchase orders and flags discrepancies for manufacturing finance teams." The example is not applicant evidence.

  3. 3

    Describe a real, urgent customer problem

    Define the initial narrow customer segment. Explain who experiences the problem, what triggers it, how often it occurs, the cost of the current workaround and why solving it matters. Include both end users and economic buyers when different. Prefer evidence of customer behavior over survey enthusiasm.

    Interview customers about the past: "Tell me about the last time this happened"; "What did you do?"; "Why was it hard?"; "What have you tried?"; "What did the workaround cost?" Do not lead the witness by pitching first. Record concrete patterns, objections, customers who do not care, and evidence contradicting the thesis. One useful structure is: WHO encounters PROBLEM when TRIGGER occurs, resorts to WORKAROUND and loses TIME/MONEY/OPPORTUNITY. Support with one or two real, sourced observations. Never fabricate quotes or interviews.

  4. 4

    Establish founder-market fit and unique insight

    Separate: Why did we choose this idea? What makes us unusually equipped to solve it? What do we know that others miss? Use personal experience, domain expertise, customer observation, distribution access or a technical breakthrough. Reject vague claims of passion or fascination with a hot sector.

    A useful structure: "Most people assume X. We observed Y, supported by Z. That changes our approach: we do A rather than B." Only use this when truthful; not every startup needs an artificially contrarian insight. Show how insight affects product design, buying process or go-to-market. For "Why now?", identify a causal shift such as technical cost/performance, regulation, distribution, buyer behavior or economics. "AI is growing fast" alone is not sufficient.

    FICTIONAL EXAMPLE: "The bottleneck isn't extracting invoice fields; it is reconciling inconsistent purchase orders, so we focus on matching before reporting." Verify before asserting it for a real company.

  5. 5

    Explain competitors, substitutes and initial wedge

    List direct competitors, indirect alternatives, manual processes, internal tools and the option to do nothing. Include credible future entrants. For each: users, strengths, weaknesses for your specific initial customer, evidence and switching costs. Never say "no competitors" when users currently accomplish the job somehow. Do not caricature large competitors or rely on unsupported claims that the product is simpler or faster.

    Draft the competitive answer: "Customers currently use A and B. These work for X, but struggle with Y in our target workflow. We use Z approach because [evidence or causal explanation]." Define a specific initial wedge and explain how it could survive incumbent responses. Identify what observation would disprove your differentiation. Review the Dropbox original application for an historical example of a clear abstraction-level difference; do not copy its claims or treat its 2007 technology landscape as current.

  6. 6

    Show founder achievements and team credibility

    For each founder, identify the strongest concrete accomplishment outside or inside this startup. Write: ACTION + DIFFICULTY + RESULT + PERSONAL CONTRIBUTION. Evidence can be shipped software, research, open source, sales from zero, organizing something difficult, exceptional independent projects or solving a constrained technical problem. Name specific numbers only if verified. Replace "I'm passionate, visionary, hardworking" with observable facts. Credentials and prior employers help only when tied to what the founder actually did.

    Document cofounder relationship, how long they have worked together, past joint accomplishments, decision-making, who writes the core product, ownership of critical capabilities, other commitments and equity when requested. Do not hide missing skills or part-time status. FICTIONAL EXAMPLE: "At 19 I built a scheduling tool used by 12 clinics and maintained it alone for two years." Never claim this unless real.

  7. 7

    Show progress with honest, stage-appropriate metrics

    Create a chronological log: when work started; time spent part-time or full-time; what shipped; product availability; interviews; activated users; repeat usage; pilots; paying customers; revenue; experiments; and decisive lessons. Prefer this pattern: "We began [time], shipped [thing] after [duration], and [N] customers now [observable action]. We learned [finding] and changed [product/strategy]."

    Define every metric. Distinguish signups vs active usage, users vs paying customers, revenue vs GMV, recurring vs one-off payments, LOIs vs signed deals, free pilots vs paid contracts, projected ARR vs realized revenue. Include periods, cohorts and denominators; "grew 300%" alone is weak. Never cherry-pick a misleading baseline.

    Match evidence to stage. Idea: meaningful domain insight and user observations. Prototype: live demo and measured technical feasibility. Early users: activation, frequency, retention. Revenue: actual payments and repeatability. Hardware, biotech or deeptech: reproducible tests, benchmarks, manufacturability or commercialization milestones. If no traction exists, state it honestly and highlight legitimate construction and learning.

  8. 8

    Explain business model and credible market expansion

    Name the user, economic buyer, pricing model and unit, price if known, purchasing process, and why the customer would pay. Clearly label proposed versus validated pricing. Explain how the first customers can realistically be acquired; do not rely only on paid ads or an unspecified viral loop.

    Use bottom-up market thinking: plausible number of buyers multiplied by credible annual spend. State sources and assumptions, then distinguish early beachhead, adjacent expansion and long-term opportunity. Avoid "we only need 1% of a $100B market." Explain why the initial wedge creates a right to expand, through product reuse, distribution, data, network effects, economics or other mechanisms. Surface sales-cycle, regulation, margin, supply and adoption risks. Do not create false precision.

  9. 9

    Draft and compress answers into plain English

    For each actual question, write the direct answer first. Follow with up to three strongest relevant facts and one implication only if needed. Edit by removing introductions, repetitions, vague adjectives, unsupported forecasts, jargon and phrases that merely sound impressive. Prefer specific nouns and active verbs. Maintain consistent tense: "we built" vs "we are building" vs "we plan to build". Keep customer evidence, metric definitions, ownership and product status accurate. Do not invent an official word-count rule; follow each current field limit.

    Use four passes: (1) FACT DRAFT: collect facts without polishing. (2) ANSWER DRAFT: lead with the response, then evidence. (3) COMPRESSION: eliminate everything not needed to answer. (4) COLD READ: test comprehension with a stranger. For each answer retain ORIGINAL / REVISED / WHY IT IMPROVED / VERIFICATION NEEDED.

    FICTIONAL BEFORE: "We have huge demand and customers love the product." FICTIONAL AFTER: "We spoke with 30 operations managers; 12 requested a demo and 4 agreed to paid pilots." After-version only works if those numbers are real. AI may help shorten or challenge a response but must not create founder achievements, users, quotes or evidence.

  10. 10

    Produce an authentic founder video and truthful demo

    Review current YC video rules. On the official video page YC asks for approximately one minute consisting only of founders talking, all founders represented, and natural spontaneous speech from bullet points rather than reading a script. The video is not a promo or a product demo.

    Suggested content: founder names and roles, what the company does, why they care or are qualified, strongest fact about progress or insight, and a short closing. Prioritize comprehensible audio, natural delivery and clear communication over production value.

    If product demo is requested in a separate field, show one complete real user task: starting condition, action inside the product, result and why it matters. Distinguish a live product from mocks or prototypes. Do not imply simulated behavior is production behavior. Check that a viewer who knows nothing about the startup can understand it without external explanation.

  11. 11

    Run cold-read, skeptical and factual reviews

    Conduct three independent reviews. COLD READER: a smart outsider reads the application alone and restates the product, customer, why it matters and why this team might win. FACTUAL REVIEW: founders check all figures, dates, time periods, commitments, equity, claims and links for consistency across application, website, demo and video. SKEPTICAL REVIEW: challenge demand, competing alternatives, buyer willingness to pay, distribution, real defensibility and market growth. Ask "How do you know?" and "What would falsify this?"

    Internal diagnostic rubric (NOT YC's rubric): score 0 = missing or misleading, 1 = plausible but unsupported or unclear, 2 = clear and substantiated, across clarity, founder strength, insight, stage-appropriate evidence, market potential and consistency. The 0-12 total helps prioritize editing; it does not forecast acceptance. A fabricated statement or material inconsistency is a blocker even with a high total.

    Prioritize corrections: factual integrity, product clarity, unsupported claims, causal insight, then stylistic cleanup. If a section is weak because the underlying hypothesis is untested, propose a product or customer experiment instead of wordsmithing it.

  12. 12

    Practice interviews and maintain reusable evidence

    Prepare crisp answers to: What are you building? Who specifically needs it? How do you know? What did customers do, not just say? What numbers matter? Why this team? What do competitors miss? How will you win your first ten customers? Why can this be big? What is the largest risk? What changed since applying?

    Run unscripted mock interviews with randomized questions and follow-up "Why?" and "How do you know?" probes. Answer first, provide a fact next, admit genuine unknowns and explain how to test them. Jessica Livingston advises conversation and specific interesting details rather than buzzwords or a prewritten pitch.

    Perform final consistency and integrity checks, verify links and current submission rules, and log genuine new progress that could be shared appropriately. Do not create an application schedule here; this playbook is intentionally batch-agnostic. End with a retrospective: strongest evidence, greatest uncertainty, rejected or misleading claims, high-value future experiments, and what to rewrite next time.