How to Write a Strong YC Application: Examples, Reviewer Notes & a Complete Guide

Your application should make the business easy to understand

Founders often try to sound ambitious when they should be specific. They describe enormous markets, sophisticated technology, and what the company might become. The reader still doesn't know what the product does today, who uses it, or why anyone cares.

A stronger application answers a simpler sequence: What problem exists? Who experiences it? What have you built? What happened when customers tried it? Why are you the right team? What have you learned that others may have missed?

Our Cedarline example is a fictionalized healthcare-workflow company. Its application describes software that handles prior authorizations for specialty clinics. The handwritten feedback identifies both strengths and opportunities to make the answers more precise.

There is no guaranteed formula for YC admission. This guide is about writing more useful, credible answers, not gaming a selection process.

1. Describe your company in 50 characters or less

This tiny field forces you to make a choice: explain the product or describe an aspiration. Choose the product. A reader should immediately know what your company does and for whom.

The reviewer considered this good, but suggested making the customer and outcome more specific, for example by naming specialty clinics. That is the right instinct: “clinics” is broad, while “specialty clinics” gives the reader a more concrete customer.

Keep the wording literal. Avoid phrases such as “revolutionizing healthcare,” “AI-powered next-generation platform,” or “the future of operations” when they crowd out the actual product.

Quick test

Could a smart person unfamiliar with your industry explain your product after reading this line once? If not, simplify it.

2. What is your company going to make?

This is where founders often lose clarity. They explain features without showing the workflow. Instead, describe what happens before the product, what the product actually does, and what changes for the customer.

Cedarline's example says clinic staff forward an order or connect their electronic health record. The software identifies payer requirements, assembles clinical evidence, submits the request, and follows it until approval or denial. The clinic sees status and missing documents in one queue.

That is useful because a reader can picture the steps. The reviewer still asks for details: Which specialties are included? Is forwarding an upload, integration, or manual process? Why start with orthopedic and pain clinics? What exactly is the initial wedge?

How to make the answer stronger

• Identify the initial customer segment, not every customer you might serve someday.
• Use plain verbs: receives, checks, submits, tracks, flags.
• Explain any integration or manual step that could otherwise sound like magic.
• Define the measurable benefit, such as staff hours saved or faster submission.
• State important limitations honestly. Cedarline notes that a trained reviewer approves submissions and that it does not make coverage or medical decisions.

One good sentence about the workflow can do more work than a paragraph of product positioning.

3. How far along are you?

Progress is not just a feature list. It is evidence that the company is moving, ideally with a clear time period and a comparison point.

Cedarline's example provides several concrete numbers:

• 14 locations across six practices.
• 2,840 authorization requests processed in September, compared with 760 in June.
• 91% of September requests submitted without clinic staff re-keying data.
• Median time from complete order to submission fell from 18 hours to 2.1 hours.
• $18,600 September revenue, comprising $15,400 recurring subscription revenue and $3,200 implementation revenue.
• 12 paying locations and two in a 30-day paid pilot.

These numbers work together. They show adoption, increasing usage, operational improvement, and money changing hands. The example also says two major customers expanded locations after their first 60 days.

The reviewer suggests improving the answer with growth context, an approval or denial success metric if available, revenue breakdown, and a short customer outcome.

Do not force metrics you do not have. Pre-revenue founders can discuss prototypes shipped, usage, pilots, customer conversations, letters of intent with clear limitations, or evidence that users return. Label each accurately. A pilot is not the same as a subscription, and a signed agreement is not the same as collected revenue.

4. If you pivoted, explain what changed and why

Do not disguise a pivot as a flawless strategy. A thoughtful change of direction can show that you listened to users and acted on evidence.

Cedarline's illustrative story begins with a broad AI inbox for clinic administration. Clinics liked the demos but did not replace their existing workflow. During interviews, practice managers repeatedly showed the founders authorizations waiting for action in insurer portals.

The team narrowed its focus to one job: submit imaging authorizations correctly with less staff time. The example says its first customer agreed to pay for that outcome before the automation was complete.

That insight is much more valuable than saying “we pivoted based on feedback.” It names the observation, the decision, and the customer outcome. The reviewer recommends adding a specific quote, time saved, or other concrete example to make the learning tangible.

Use this structure

1. What was the original idea?
2. What did customers actually do or refuse to do?
3. What did you change?
4. What evidence suggests the new direction is better?

5. Why did you pick this idea? Why are you the right people?

Founder-market fit should be demonstrated through experience and action, not just enthusiasm. What have you seen, built, researched, or lived that gives you an advantage?

In Cedarline's example, one cofounder led revenue-cycle operations for a 22-provider orthopedic group. The other previously built workflow software integrated with electronic health records and unreliable third-party systems.

That combination is specific. One founder understands the day-to-day pain; the other understands the technical constraints. The reviewer suggests adding the founders' exact roles and years of experience, where helpful.

If you do not have industry experience, show how you have earned insight: customer shadowing, manual service delivery, repeated experiments, or a product you built because of a problem you encountered directly.

6. How do you know people need what you're building?

Survey enthusiasm and compliments are useful signals, but they are weaker than behavior that costs the customer something: time, money, a workflow change, or a commitment to use the product.

The Cedarline example says the founders shadowed staff at 11 clinics and manually completed 310 authorizations before writing the first automation. Eight practices asked for a pilot; six signed; five expanded or renewed after the initial term.

This is persuasive because the team did the work before trying to automate it. It also shows a progression from research to real usage and payment.

The reviewer recommends adding the timeframe and a measurable outcome, such as faster approvals or time saved. If a claim has not been measured, do not invent a number to make it sound stronger.

7. Who are your competitors, and what do you understand that they don't?

“We have no competitors” is rarely informative. Customers already solve the problem somehow, even if the solution is spreadsheets, staff, outsourcing, or a general-purpose tool.

Cedarline names the clinic's own authorization team, spreadsheets, payer portals, outsourced billing vendors, revenue-cycle platforms, and prior-authorization software as alternatives. It then explains the key insight: the expensive part is not filling out one form, but maintaining a request through missing-document notices, payer-specific rules, portal errors, and repeated status checks.

That is a stronger differentiator than simply claiming to use better AI. It identifies an overlooked part of the workflow and explains why a broader product may not solve it well.

What the reviewer would improve

• Name one or two specific competitors where relevant.
• Explain the actual difference, not just “we are faster.”
• Include comparative results only when supported by evidence.
• Explain why your starting market is narrow and why that is an advantage.

A strong answer can acknowledge that competitors are capable while showing a precise insight about customer needs or execution.

8. How do you or will you make money?

Explain the buyer, the pricing unit, the expected customer bill, and the major costs. Avoid describing a market-size fantasy when a simple example would make the economics clear.

Cedarline charges a $450 monthly platform fee per location plus $4 per completed authorization workflow. A location processing 300 requests per month pays $1,650. The example also mentions a one-time implementation fee when custom EHR mapping is required.

The application reports 63% gross margin at current usage, including human review and third-party integration costs, and a target of 75% as more follow-up tasks are automated. These are example-company figures, not external benchmarks.

The reviewer asks for customer acquisition detail, typical sales cycle, retention or expansion data, and cost drivers. Those are sensible additions when you have reliable answers and space.

What if you are pre-revenue?

State the proposed pricing model and who would pay. Explain the evidence behind your assumptions, such as pricing conversations or paid pilots. Do not present projections as revenue or estimates as established margins.

The YC application self-review checklist

Before submitting, read your answers as someone who has never met you. Can they understand the company without a pitch deck, a demo call, or industry jargon?

• The one-line description says what the product does and for whom.
• The product answer describes a real workflow rather than a list of buzzwords.
• The customer segment is specific, especially the initial wedge.
• Every metric has a clear definition and timeframe.
• Revenue, pilots, signups, and active users are not mixed together.
• Any pivot explains the evidence and resulting decision.
• The founder story shows concrete experience or earned insight.
• Customer demand is supported by observed behavior.
• Competitors include existing workarounds, not just similar startups.
• The differentiation is specific and defensible.
• The pricing model is understandable with a simple example.
• Claims, numbers, and timelines are consistent across answers.
• Every answer is direct, accurate, and written in your own voice.

Finally, remove sentences that only say you are “innovative,” “disruptive,” or “uniquely positioned.” Replace them with a fact or delete them.