Applications · 12 min read

How to Describe Your Progress Section in the YC Application

Short answer

The progress section of the YC application is where most founders undersell the most. Not because they lack evidence — but because they do not know what counts as evidence in this context, or they present real evidence in a form that does not land with partners. The progress section is your single highest-leverage field for demonstrating that your company is real, moving, and worth 10 minutes of a partner's time.

What the Progress Section Is Actually Asking

Partners read hundreds of progress sections per batch. The ones they remember answer a single question with maximum specificity: what has actually happened since you started building this company?

The YC application asks: "How far along are you? Do you have a product? Any users? Any revenue?"

What partners are actually evaluating through this field:

Is this company real or hypothetical? The most important signal. A company with specific, dated evidence of activity — customers acquired on a specific date, a specific version of the product shipped, a specific conversation with a named user type — is real. A company described entirely in future tense is hypothetical.

Is this founder moving fast enough? Partners compare what you have built against how long you have been building. 14 months with 3 users is a slow pace. 6 weeks with 23 paying customers is a fast one. The absolute numbers matter less than the ratio of evidence to time elapsed.

What is the quality of the evidence? There is a hierarchy of evidence in the progress section: paying customers (strongest), unpaid active users with strong retention, signed LOIs or pilots, prototype tested with real users, prototype built but not yet tested, concept with no prototype (weakest). Know where you sit on this hierarchy and write accordingly.

The Answer Layer: How to Write Each Stage of Progress

If You Have Paying Customers

This is the strongest possible progress section. State the following in this exact order:

  1. Number of paying customers (exact, as of a specific date)
  2. Monthly recurring revenue (exact number)
  3. Retention rate (exact metric, exact window)
  4. How you acquired them (the specific channel, not "through marketing")
  5. What they pay and what they use the product for
  6. The earliest and most recent customer acquisition date

Example:

"23 paying customers as of October 14, 2024. ₹64,400 MRR. Month-2 revenue retention: 89%. All 23 came from direct outreach in 12 pharmacy owner WhatsApp groups across Maharashtra. Average contract: ₹2,800/month for inventory tracking and expiry alerts. First customer: August 3. Most recent: October 11."

That is 60 words. It contains 7 specific data points. A partner reading it can reconstruct your acquisition motion, evaluate your retention, assess your pricing, and verify the timeline.

If You Have Free Users But No Revenue

State the strongest behavioral evidence you have — not just signup numbers, but evidence of genuine engagement and value:

  1. Number of active users (distinguish total signups from monthly actives)
  2. Retention (Day-7 or Day-30 — be specific about the window)
  3. The specific behavior that signals value (not just "users love it")
  4. Any monetization signal (users who asked to pay, who gave payment information, who upgraded from free)
  5. When you launched and how you acquired these users

Example:

"340 monthly active users, 11 weeks after launch. Day-7 organic retention: 61%. Top usage behavior: users generate an average of 4.2 inventory reports per week — our hypothesis was 1-2 per week. 6 users have asked how to pay; 3 have given us credit card information for when we launch paid tiers. Acquired entirely through founder's personal network of 47 pharmacy owner WhatsApp groups."

If You Have a Working Prototype But No Users

State specifically what the product does, who has seen it, what their reaction was, and what specific evidence of demand you have gathered:

  1. What the product does today (not what it will do)
  2. Who has used or seen it (number, user type)
  3. What they said or did that constitutes demand evidence
  4. Any pre-commitment evidence (waitlist with payment, signed LOI, deposit paid)
  5. When you built it and how long it took

Example:

"Working prototype of our WhatsApp-native inventory system built over 8 weeks. Tested with 14 pharmacy owners across 3 cities — 11 said they would pay ₹500-1,500/month for the current version. 3 have agreed to pay on launch and given us their WhatsApp numbers to be the first to receive the link. One distributor has agreed to pilot our returns integration when we launch. No live users yet — launching in 3 weeks."

If You Are Pre-Prototype (Idea Stage)

This is the hardest stage to write a strong progress section. The temptation is to describe what you are going to build. Resist it entirely. Write only about evidence of demand and team activity:

  1. Number of user interviews conducted (must be substantial — 20+ to carry weight)
  2. The specific, non-obvious thing you learned that justifies building this
  3. Any behavioral evidence of demand (someone who offered to pay, who changed their behavior because of a conversation with you)
  4. What the team has built in adjacent areas or what specifically qualifies the team to build this quickly
  5. What you have done in the last 30 days that proves you are moving

Example:

"No product yet. 67 user interviews with independent pharmacy owners across Maharashtra and Gujarat over 8 weeks. The non-obvious finding: 72% of respondents identify stock loss to expiry as their most painful operational problem — more painful than theft, payment delays, or distributor issues. We did not expect this ranking. We asked them to rank 7 pain points; expiry loss won unprompted in 72% of cases. 4 owners offered to pay before we mentioned pricing. We are building the prototype this week."

The Data Layer: The Evidence Hierarchy and What Each Level Signals

Partners weight progress evidence on an implicit hierarchy. Know where your evidence sits:

Evidence TypeWeightNotes
Paying customers with retention dataHighestState exact MRR, exact retention, exact CAC
Revenue from any source (consulting, pilots, one-time)HighShows willingness to pay; less predictive than recurring
Active free users with strong behavioral retentionMedium-highDay-7 and Day-30 organic retention are the key metrics
LOIs, signed pilots, or pre-paymentsMediumStronger if non-refundable; name the user type
Prototype with user feedback and pre-commitmentMediumState specific feedback and specific pre-commitment evidence
Prototype tested with no user reactions recordedLow-mediumShows you can build; weak demand signal
Waitlist signupsLowEasy to acquire; rarely meaningful without behavioral data
User interviews with strong insightsLow-mediumOnly strong if the insight is genuinely non-obvious
Team credentials and past achievementsLowestContext, not progress

What "Progress" Is Not

Partners are explicit about this: the following do not count as progress evidence:

  • Media coverage or press mentions
  • Academic publications or research citations
  • Advisor or investor names
  • Contest wins or accelerator acceptances (other than YC itself)
  • App store downloads without active user data
  • Social media followers without conversion evidence

These items can appear as supporting context but should never be the primary content of your progress section.

The Context Layer: The Four Progress Section Mistakes

Mistake 1: Mixing past progress with future plans

The progress section should describe only what has happened, not what you plan to do. "We have 14 customers and plan to reach 50 by Q1" — the second half of that sentence belongs in the growth plan field, not the progress section. Keep the progress section entirely in the past tense.

Mistake 2: Reporting vanity metrics instead of retention metrics

"10,000 app downloads" without active user data is a vanity metric. "2,400 monthly active users" is a real metric. "61% Day-7 organic retention" is a retention metric. Downloads, page views, and social shares are not progress evidence. Active users with retention data are.

Mistake 3: Understating progress out of modesty

Founders frequently write "we have some early customers" when they mean "we have 23 paying customers at ₹64,400 MRR." The modesty is counterproductive — it produces less impact than the specific numbers would. Partners cannot be impressed by numbers you do not name. Write the number. Say it confidently.

Mistake 4: Reporting aggregate progress without a timeline

"We have 23 customers" is weaker than "we have 23 customers acquired over 10 weeks, with the first customer on August 3 and the most recent on October 11." The timeline tells partners your pace — which is information about your execution velocity that the aggregate number alone cannot convey.

Keep reading

More on Applications

Go deeper

Want the full data behind this answer?

Our YC database tracks 5,000+ companies, every batch, with application patterns, founder backgrounds, and pivot stories — the raw material we built this answer on.

FAQ

Frequently asked questions

What is the most important thing to include in the YC application progress section?
The most important thing is exact, specific evidence of real user or customer engagement — stated with precise numbers, precise dates, and precise descriptions of how you got there. Paying customers with retention data is the strongest possible progress section. If you have no paying customers, the most important thing is the strongest available behavioral evidence that real people value what you are building: active users, retention data, or documented pre-commitment from people who have offered to pay.
How do you write a strong progress section if you have zero revenue and zero users?
Focus exclusively on what you have done and what you have learned, stated specifically. The number of user interviews matters less than what those interviews revealed — name the specific, non-obvious insight they produced. Any behavioral evidence of demand (someone who offered to pay, who asked for early access, who changed their behavior based on a conversation with you) should be named precisely. Describe what the prototype does today, who has seen it, and what they specifically said or did in response.
Should you include team background and credentials in the progress section?
No. Team background belongs in the founder fields, not the progress section. The progress section is exclusively about what has happened with the company — product built, users acquired, revenue generated, demand validated. Mixing team credentials into the progress section dilutes the progress evidence and signals that you are padding the section because you do not have enough actual progress to fill it.
How recent does progress need to be to be relevant in the YC application?
As recent as possible. Progress from the last 90 days is the most relevant — it shows current momentum. Progress from 6-12 months ago is context, not current evidence. If your most significant traction milestone happened 8 months ago and nothing significant has happened since, partners will notice the gap and ask about it. Continuous progress — new customers, improving retention, new product features — is a stronger signal than a single historic milestone.
What if your progress looks slow compared to what you think YC expects?
Be honest about it and contextualize it accurately. If you have been building for 18 months with 3 customers, acknowledge that the pace has been slower than you would like and explain specifically why — a regulatory barrier, a longer enterprise sales cycle, a pivot that cost 6 months, a technical challenge that has now been resolved. Then state what has changed that makes the next 6 months different. Partners can fund slow-moving companies if the reason for the pace is structural (not laziness or misalignment), the explanation is honest, and the founder demonstrates clear self-awareness about what needs to change.
How much detail is too much in the progress section?
Enough to answer: what exists, who is using it, what are they paying, and how did you get them — stated in precise numbers and brief context. Two to four paragraphs of dense, specific information is typically the right length. Beyond that, you are likely including information that belongs in other fields. Within that length, more specificity is always better than more words.
Should you include negative progress — things that didn't work — in the progress section?
Only if it directly informs what you are building now and demonstrates the learning that came from the failure. "We built a desktop app, acquired 4 users, and all 4 churned within 2 weeks because none of them opened the desktop application after setup. That experience is why we rebuilt entirely on WhatsApp — our current 23 customers have 89% month-2 retention." That is honest, specific, and demonstrates learning embedded in the product. Mentioning failure without the lesson or without the current evidence of improvement is less useful.
Can you update the progress section after submitting the YC application?
YC allows applicants to submit updates to their application after submission if significant new progress occurs. A meaningful update — a new major customer, a significant revenue milestone, a key regulatory approval — is worth communicating in a brief, specific email to the YC application team. Routine updates or minor progress changes are not worth communicating. The bar for an update email: would this specific piece of information meaningfully change a partner's evaluation of our application? If yes, send it.
How do you write the progress section for a company that has pivoted recently?
Be transparent about the pivot and focus the progress section on the evidence relevant to the current direction. "We spent 8 months building a B2B inventory tool for restaurants before pivoting to pharmacies in June. In 4 months since the pivot, we have 23 paying customers at ₹64,400 MRR — more revenue than we generated in the entire 8-month restaurant period." That framing is honest about the pivot, shows self-awareness about why the pivot was necessary, and leads with the strongest current evidence.
What is the difference between progress and traction in the YC application?
Progress is the broader category — everything that has happened to build the company. Traction is specifically the evidence of market demand: customers, revenue, retention, user engagement. Progress includes traction but also includes product milestones (launched a new feature, rebuilt the architecture, received a patent), team milestones (hired a key engineer, brought on an advisor with relevant relationships), and business milestones (signed a partnership, received a grant, established a regulatory pathway). In practice, the strongest progress sections lead with traction evidence and follow with other progress context.
How do hardware or biotech founders write the progress section differently?
By substituting scientifically validated milestones for revenue traction where revenue is not yet appropriate given development timelines. "We have demonstrated X performance metric in Y testing conditions with Z sample size" replaces "we have X paying customers at Y MRR." The key is that the milestone must be specific, must be externally validated where possible, and must clearly move the company toward commercial launch. "We are making good progress in the lab" is as weak for a biotech company as "we have some early customers" is for a SaaS company. Name the specific milestone, the specific metric, and the specific date.
How do you write the progress section if your company is less than 4 weeks old?
Focus entirely on what exists right now and what evidence of demand you have gathered — even if both are early. "We incorporated 3 weeks ago. We have a working prototype built over 2 weeks, tested with 8 users from the founder's personal network. Three of the 8 asked to be notified when they can pay. We have conducted 22 user interviews in the last 10 days — the most consistent finding across all 22 is [specific observation]." That answer is honest, specific, and shows that you are moving fast. A 4-week-old company is expected to have early-stage evidence, not polished metrics — what partners are evaluating is whether you are building and learning at a pace that suggests you will have significant traction in 6 more months.

An independent resource · Not affiliated with Y Combinator · Last updated 2026-08-04