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

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.

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.