Applications · 12 min read
Should You Apply to YC With a Prototype or Just an Idea
Short answer
Apply with a prototype. Every time. If you have a choice between waiting to build a prototype and applying now with just an idea, build the prototype first. This is not a nuanced answer that depends on your sector, your team, or your timeline. A working prototype — even a minimal, buggy, limited one — is fundamentally more credible than an idea, and the gap in application quality between "we have built X" and "we plan to build X" is large enough to materially affect your acceptance odds.
Why a Prototype Changes Everything
A prototype is not valuable because it demonstrates technical skill. It is valuable because it proves four things that an idea cannot prove:
1. The founders have started. Motion is a signal. Two founders who have built something — anything — have demonstrated that they can move from intention to execution. Partners reading 50,000 applications are hyperaware of this signal. "We have built X" and "we plan to build X" read completely differently.
2. The product concept is concrete. An idea that has been built into a prototype has been stress-tested against reality. The founders have had to make specific decisions — what to build first, what to exclude, what the user interface looks like — that reveal their product thinking. An idea that has not been built is still theoretical.
3. You have talked to users with something real to show. User reactions to a live prototype are significantly more informative than user reactions to a description of a product. If your prototype has been used by even 3 people, you have evidence of user behavior that is more credible than any number of interviews about a hypothetical product.
4. The founders can build. For technical products, a working prototype is the clearest possible signal of technical execution ability. For non-technical founders, a no-code prototype or manual service version proves that the product concept is buildable even before you have hired an engineer.
The Answer Layer: What YC Expects at Each Stage
Idea only (no prototype, no users): Fundable in rare cases when founder-problem fit is so deep and so specific that the absence of a product can be compensated. The bar is extremely high. You need: a personal connection to the problem that is visceral and provable, 60+ user interviews with a genuinely non-obvious insight, and at least some form of pre-commitment from potential users (signed LOIs, paid deposits, users asking when they can pay).
If you have all of these, apply now without a prototype. If you are missing even one, build a prototype first.
Working prototype, no users: Meaningfully stronger than idea-only. You have demonstrated execution ability and made concrete product decisions. The gap is user evidence. The right action: get your prototype in front of 5-10 real users before applying. Even one week of real usage generates retention data and behavioral observations that the application can cite. Do not submit an application about a prototype that nobody has used yet.
Working prototype, some users: The right minimum for a credible application. "We have a working prototype that X users have been using for Y weeks. Z% of them have come back at least once." This sentence alone — with real numbers — is more credible than most of what YC receives.
Working prototype, paying customers: Ideal. Combine paying customers with retention data and you have a complete answer to YC's core evaluation question: does your product create enough value that people will pay for it repeatedly?
What Counts as a Prototype
The word "prototype" covers a wide range. Any of these qualify:
A coded MVP: A working software product, even if limited in features, built in code. This is the most credible type of prototype for technical founders.
A no-code MVP: A functional product built with no-code tools — Glide, Bubble, Webflow, Airtable, Zapier, WhatsApp Business. No-code products that real users use are fully credible prototypes. The tool you used to build it does not matter.
A Wizard of Oz prototype: A product that appears automated to users but is actually manually operated by the founders behind the scenes. Classic example: a "chatbot" that is actually a founder responding to messages. If users are getting value and some are paying, this is a valid prototype.
A manual concierge service: You personally deliver the service manually that your software will eventually automate. Users pay you for the manual service. This is both a prototype and traction simultaneously.
A working spreadsheet or template: For products that are essentially structured data workflows, a complex working spreadsheet that users are relying on for real work is a prototype. One pharmacy owner who uses your Google Sheet to track expiry is more credible than a mockup of what the app will look like.
What does not count as a prototype: Figma mockups, slide decks, wireframes, or descriptions of what you plan to build. These are designs, not prototypes.
The Data Layer: How Prototype-Stage Applications Perform
Based on publicly available founder accounts and YC partner commentary:
Applications with a working prototype and 5+ active users have materially higher interview rates than applications with just an idea and identical founder credentials.
The specific type of prototype matters less than the evidence of usage. A WhatsApp-based manual service with 10 paying users outperforms a polished coded MVP with zero users.
The gap between prototype and no-prototype is larger than any other single application variable except very strong/very weak founder-problem fit. Teams of equal quality with equal market insight get different outcomes based primarily on whether they have built something.
The Context Layer: The Fastest Path to a Prototype
If you have an idea and no prototype, here is the fastest path to something you can apply with:
Week 1-2: Define the single core workflow What is the one thing your product does that creates value for users? Not the feature set — the one workflow. For a pharmacy expiry tracker: "pharmacy owner enters stock, gets alert when medicine is about to expire." That is the core workflow. Build only that.
Week 2-4: Build the minimal version For technical founders: build only the core workflow in code. No user accounts, no dashboard, no settings — just the one thing. For non-technical founders: build it in no-code tools (Glide for a mobile app, Airtable + Zapier for a workflow tool, WhatsApp Business for a chat-based service).
Week 4-5: Get 5 real users Find 5 people who have the problem. Ask them to use your prototype. Watch them use it. Note what breaks, what confuses, and what delights. Do not ask if they like it — watch what they do.
Week 5-6: Fix the critical failure and apply Fix whatever broke for the first users. Then apply. You now have a prototype with 5 users and usage data. That is a credible application.
Six weeks from idea to credible application is achievable for most products with a motivated founding team.
When Applying Without a Prototype Is Justified
Biotech, medtech, or regulated hardware: Physical products or regulated products may genuinely require 6-12 months before any usable prototype exists. In this case, pre-prototype applications are expected and your application should compensate with: clinical validation data, regulatory pathway progress, scientific evidence for the core mechanism, and a team with deep domain credentials.
Deep research or novel technology: If your product requires a genuinely new scientific or technical capability that cannot be demonstrated in a prototype without 12+ months of R&D, the application must compensate with: published research, team credentials, and a clear description of the specific technical milestone that proves the core mechanism works.
Discovery-stage products with exceptional founder-problem fit: Founders who have spent years in an industry and have a specific, non-obvious insight into a problem that they are uniquely positioned to solve — and can demonstrate this with specific research — can occasionally be funded before a prototype. This is the rarest case and requires the strongest possible founder-problem fit story.
Keep reading
More on Applications
How to Write a YC Application That Gets an Interview in 2025
10 min read
YC Application Word Limits — What to Write in Each Field
11 min read
How to Answer "What Is Your Company?" on the YC Application
10 min read
YC Video Essay Tips — What YC Partners Actually Want to See
11 min read
Founder Stories
Want the real version of these answers? Read long-form, source-linked stories from actual YC founders — how they got in, what broke, what scaled.
Read Founder Stories →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
Can you get into YC with just an idea and no product?
How polished does a prototype need to be for a YC application?
Can a no-code prototype be enough for a YC application?
What is a Wizard of Oz prototype and is it valid for YC?
Should I wait until I have paying customers before applying to YC?
Is it better to apply to YC earlier with less traction or later with more traction?
How should a non-technical founder build a prototype without an engineer?
What if your prototype is embarrassingly basic — should you still include it?
How do YC partners evaluate a prototype during the interview?
Should you apply to YC if your prototype breaks frequently?
What happens if your prototype has significantly changed by the time you get a YC interview?
How do you describe a manual concierge prototype in the YC application without it sounding unsophisticated?
An independent resource · Not affiliated with Y Combinator · Last updated 2026-02-01