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

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?
Yes, but it is rare and the bar is very high. The cases where it works share a specific profile: the founder has exceptional personal connection to the problem, has done 60+ user interviews with a genuinely non-obvious insight, and has some form of pre-commitment from potential users. An idea without these elements has almost no chance. The practical advice for most founders: spend 4-6 weeks building a minimal prototype before applying. The uplift in application quality is significantly larger than the cost of waiting.
How polished does a prototype need to be for a YC application?
Not polished at all. YC partners are evaluating whether the product creates value for users — not whether it looks good. A rough, functional prototype with real users is more credible than a polished prototype with no usage. The key is that it works well enough that real users can accomplish the core task without significant friction. If users can complete the core workflow independently, your prototype is ready for an application regardless of its visual design.
Can a no-code prototype be enough for a YC application?
Yes. YC has funded companies that started with no-code prototypes built in Glide, Bubble, Webflow, Airtable, and similar tools. The tool used to build the prototype is irrelevant. What matters is whether real users are getting value from it. A Glide app with 20 active users and 85% weekly retention is a more credible application than a coded product with zero users.
What is a Wizard of Oz prototype and is it valid for YC?
A Wizard of Oz prototype appears automated to users but is actually operated manually by the founders behind the scenes. A "chatbot" that is actually a founder typing responses, a "recommendation engine" that is actually a founder manually curating results, or a "matching algorithm" that is actually a founder making manual matches are all examples. These are fully valid for YC applications when users are genuinely getting value and especially when they are paying. The classic YC framing is "do things that don't scale" — a Wizard of Oz prototype is the literal embodiment of this principle.
Should I wait until I have paying customers before applying to YC?
If you are within 4-6 weeks of your first paying customer, yes — wait. One paying customer changes the application from "people might want this" to "someone paid for this." That qualitative shift is worth the 4-6 week delay in almost every case. If your first paying customer is 3+ months away, apply now with your prototype and user evidence and do not wait indefinitely for revenue that may take longer than expected.
Is it better to apply to YC earlier with less traction or later with more traction?
Later with more traction is almost always better, up to the point where you no longer need YC. The risk of applying too early — with insufficient evidence — is that you use your application on a weaker version of your company. The risk of applying too late — when you have grown past the stage where YC adds value — is smaller than most founders think. YC funds companies at a wide range of stages. More traction makes a stronger case. Apply when your evidence is as strong as you can make it in the current batch window.
How should a non-technical founder build a prototype without an engineer?
Use no-code tools for the simplest possible version of the core workflow. Glide for mobile apps, Bubble for web apps, Airtable + Zapier for data workflow products, WhatsApp Business for conversational products. Alternatively, run a manual service version: deliver the core product workflow manually to 5-10 users and charge them for it. This is simultaneously a prototype and traction. The manual service version is often more credible than a no-code prototype because it forces you to understand every step of the user workflow before you automate it.
What if your prototype is embarrassingly basic — should you still include it?
Yes. An embarrassingly basic prototype that real users are using is more credible than no prototype. Do not let perfectionism prevent you from applying with what you have. The application should be honest about the prototype's limitations: "Our current product is a WhatsApp bot that handles one workflow — daily stock entry and expiry alerts. It does not yet have a dashboard, payment integration, or multi-user support. But 11 pharmacy owners have been using it for 6 weeks and 10 of them are still active." That description is completely credible.
How do YC partners evaluate a prototype during the interview?
Partners typically ask to see the product during or after the interview — either a live demo or a product walkthrough. They will ask about the core workflow, what users say about it, and what you would build next. Be prepared to demo the product live and be honest about its current state. Founders who cannot demo their own product fluently in an interview raise concerns about how well they know their own product.
Should you apply to YC if your prototype breaks frequently?
If the core workflow works reliably enough that users can complete it independently, you can apply. If the prototype breaks during the workflow you would show in a demo, fix it before applying. A prototype that does not work reliably during a demo tells partners that either the product is too early or the team has not prioritized making it work. Neither is a credible signal at the application stage.
What happens if your prototype has significantly changed by the time you get a YC interview?
Disclose it in the interview. "Since we submitted our application 6 weeks ago, we have rebuilt the core workflow based on user feedback — here is what it looks like now." That update is a positive signal — it shows that you have been iterating based on real usage rather than freezing the product at the application stage. The updated version should be stronger than what was described in the application. If it is materially different in ways that change the business model or user description, acknowledge that directly and explain the reasoning.
How do you describe a manual concierge prototype in the YC application without it sounding unsophisticated?
Frame it as deliberate and strategic, not as a stopgap. "We are currently running a manual version of the service for 8 pharmacy owners. We do the expiry reconciliation manually every Sunday using WhatsApp and a Google Sheet. 7 of the 8 are paying ₹1,500/month. We are doing this manually because it forces us to understand every step of the workflow before we automate it — and because it generates real revenue while we build." That framing positions the manual approach as a founder choice, not a technical limitation.

An independent resource · Not affiliated with Y Combinator · Last updated 2026-02-01