Y Combinator Application Playbook

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.

   STARTUP-FRIENDLY INTAKE: Do not require a complete application briefing. If the optional startingPoint is empty, invite a one-sentence company or idea description. Ask for the company's stage only if useful for the next decision. Do not request founders, revenue, customer research, market sizing, financials and full form questions all at once. Collect those progressively in their dedicated steps. If the user already supplied information, reuse it without asking again.

   Documents www.ycombinator.com/howtoapply.html

   Documents www.ycombinator.com/apply/

   Expected outputs
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.

   JUST-IN-TIME INPUT: If the one-liner cannot be written from available context, ask for the target user, the core product action, and whether the product exists yet. Do not require a market model or traction here.

   Documents www.ycombinator.com/blog/how-to-pitch-your-company/

   Documents www.ycombinator.com/howtoapply.html

   Expected outputs
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.

   JUST-IN-TIME INPUT: Ask for specific customers, last-observed problem incidents, current substitutes, interviews, or direct usage evidence only as needed for this step. Capture missing evidence as an unknown instead of blocking the workflow.

   Documents www.ycombinator.com/blog/startup-school-week-1-recap-kevin-hale-and-eric-migicovsky/

   Expected outputs
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.

   JUST-IN-TIME INPUT: Here, ask about the founders' relevant experiences, surprising observations and product decisions. Don't require a full founder biography at intake.

   Documents www.ycombinator.com/blog/startup-school-week-1-recap-kevin-hale-and-eric-migicovsky/

   Documents www.ycombinator.com/apply/dropbox

   Expected outputs
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.

   JUST-IN-TIME INPUT: Ask what users currently use instead and which alternatives have actually been tested. Research additional relevant competitors as needed; if evidence is absent, mark comparisons as hypotheses.

   Documents www.ycombinator.com/apply/dropbox

   Documents www.ycombinator.com/howtoapply.html

   Expected outputs
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.

   JUST-IN-TIME INPUT: Collect founder names/roles, personal achievements, how they met, actual product ownership, time commitment, and equity details only now, and only when relevant to the current form. Facts already known must be reused.

   Documents www.ycombinator.com/howtoapply.html

   Documents www.ycombinator.com/blog/startup-playbook/

   Expected outputs
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.

   JUST-IN-TIME INPUT: Request stage-specific verified dates, product milestones, usage data, paid customers, pricing and revenue only here. It is valid to report no launched product, users, or revenue. Never make metric fields mandatory at the start.

   Documents www.ycombinator.com/blog/how-to-pitch-your-company/

   Documents www.ycombinator.com/blog/doordash-from-application-to-ipo/

   Expected outputs
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.

   JUST-IN-TIME INPUT: Ask for buyer, price tests, acquisition observations and realistic initial market assumptions at this stage. Do not demand precise TAM figures when the business is too early.

   Documents www.ycombinator.com/blog/how-to-pitch-your-company/

   Documents www.ycombinator.com/blog/startup-playbook/

   Expected outputs
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.

   JUST-IN-TIME INPUT: Obtain the actual current YC form questions and response limits now if not already available. Otherwise draft against the question map and flag which fields need later verification. Never require users to paste the complete form to begin the playbook.

   Documents www.ycombinator.com/howtoapply.html

   Documents www.ycombinator.com/blog/how-to-pitch-your-company/

   Documents www.ycombinator.com/blog/startup-school-week-8-recap-adora-cheung-on-prioritizing-your-time-and-kevin-hale-on-evaluating-startup-ideas/

   Expected outputs
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.

    Documents www.ycombinator.com/video

    Documents www.ycombinator.com/blog/doordash-from-application-to-ipo/

    Expected outputs
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.

    Documents www.ycombinator.com/howtoapply.html

    Documents www.ycombinator.com/blog/how-to-pitch-your-company/

    Expected outputs
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.

    Documents www.ycombinator.com/blog/tips-for-yc-interviews

    Documents www.ycombinator.com/blog/startup-school-videos/

    Documents www.ycombinator.com/video

    Expected outputs