www.ycombinator.com/howtoapply.html

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.

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.

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.

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.

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.

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.