Fundraising

YC Application Tips

View as Markdown

These tips skew toward B2B SaaS, but the frameworks apply broadly. The single most important thing: show, don't tell — and ask yourself why is YC asking this question? before answering any of it.

General advice

Use the recommendation system. If someone can advocate strongly for you, ask them. Most applicants don't know it exists.

Show, don't tell. Specific details beat vague claims every time. Don't say "I have industry experience" — say how many years, how many hours a day, how many people you've spoken to. Don't say "I know Django" — say how many projects, how many users. Paint a picture of expertise rather than asserting it.

Cut the fluff. Be concise and plain. Buzz-words and hype obscure your message; they don't strengthen it. This matters most in the product description, which should be the clearest part of your application.

Don't skip the personal section. Some teams get accepted on the strength of who they are, even if the idea needs work. YC bets on people — a history of being exceptional tends to continue. Write strong personal statements.

Think about the motivation behind each question. YC receives enormous volumes of applications. A technically correct answer that misses what the question is really probing will cost you an interview. Ask yourself what risk or concern the question is trying to surface, then address it directly.

Apply even if you're unsure. About 40% of accepted startups are just ideas at the time of application. It's a life-changing experience regardless.

Question-by-question tips

How long have you known your cofounder?

The underlying concern is cofounder conflict — one of the most common reasons startups fail, and a real risk during and after the batch.

YC wants evidence that you and your cofounder have already navigated disagreements together, not just that you get along. Mention things like: living together, doing everyday activities together, past projects you've shipped as a team, or a brief anecdote about resolving a real conflict. A sentence or two of concrete evidence is far more convincing than "we're really close."

Don't assume you're immune to this. If your situation is genuinely different, explain why.

Who writes code, or does other technical work? Was any done by a non-founder?

The real question is: are you the right team to build this? A brilliant idea paired with the wrong team is still a pass.

YC expects your team to build the product through the batch — without outsourcing the technical work or hiring engineers first. Both cofounders being technical is ideal. If you're solo, being technical is essentially required.

This is about product risk: can you build it?

Describe what your company does in 50 characters or less

The most common mistake is vagueness. Be specific.

If you can't describe what you do clearly in a few words, it often signals the idea itself isn't fully formed. You'll need to explain your company to investors and customers this concisely anyway — the application is good practice.

Strong examples:

  • Rippling — One place to run all your HR, IT, and Finance
  • Instacart — Marketplace for grocery delivery and pickup
  • Zepto — 10-Minute Grocery Delivery in India

In each case you know exactly what they do.

Where would the company be based after YC? Why?

YC's own data (from the W17 batch and others) shows that the overwhelming majority of companies still operating are based in San Francisco. If you're not planning to be in SF, you need a compelling reason.

NYC, London, and other cities may seem appealing — but that appeal is exactly the problem. Fun and distractions slow you down. Proximity to the startup ecosystem in SF is a genuine advantage.

How far along are you? How long have you been working on this?

This question is about product velocity — how fast can you build, ship, and incorporate feedback?

Speed of iteration matters because you almost certainly don't know yet exactly what customers want. The only real test is the market. The faster your feedback loop, the faster you converge on something people actually want.

A team iterating weekly will test 12 hypotheses in three months. A team iterating monthly will test 3. With AI tools available today, slow iteration is hard to excuse.

Think about this not just for the application, but for how you actually work. If your loop is slow, diagnose why.

Do you have users? Are they paying?

Paying users are a strong signal — mention them prominently. But depth of engagement matters as much as breadth. Five users who use your product for three hours a day is a stronger signal than thirty who signed up and never came back.

If you have power users, describe them and how they use the product.

You don't need paying users — or any users — to get accepted. ~40% of accepted companies are just an idea at application. But if you do have users, show that they love it.

What does your product do?

Be specific. Partners reading applications don't want to work to figure out what you do, and vague descriptions come across as unfocused thinking.

Cut lines like "we will revolutionize X" and replace them with what you actually do.

Before: "We revolutionize building apps using AI to make developing them faster."

After: "We're a devtool that turns Figma designs into React + Tailwind code."

Enthusiasm is fine — just make it concrete.