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

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.

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.

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.

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.