How to Answer "What Have You Built So Far?" at YC Interview

Partners ask this question to answer three specific things about you: do you move fast, do you learn from users, and is what you have built producing real signal? A product walkthrough answers none of these. A specific account of what you built, what happened, what you changed, and what you learned does.

Speed of execution. How much have you built in how much time? Founders who have been working for 9 months and have a working product with paying customers move faster than founders who have been working 9 months and are still in development. Partners have a rough internal benchmark for what a capable founding team should have produced by various stage milestones. Your answer is being measured against that benchmark.

Iteration quality. Did you build, learn, and change — or did you build and defend? The most credible "what have you built" answers include at least one explicit moment of learning from users that changed what you were building. This demonstrates a product development process that is grounded in user reality rather than in founder assumption.

Distance traveled. The most compelling version of this answer shows the delta — where you started versus where you are now. A team that started with a desktop product, learned that their users never open desktop applications, and rebuilt entirely on WhatsApp in 6 weeks has demonstrated more valuable capability than a team that built their original vision and is still building it.

Structure your answer in four beats:

Beat 1 — What you built first (one sentence)

The initial version. Not the current version. The first thing you shipped to real users. This sets up the distance-traveled story.

Beat 2 — What happened when real users used it (one sentence)

The specific thing users did or said that changed what you were building. Name a real observation, not a general trend.

Beat 3 — What you changed as a result (one sentence)

The specific product change you made. Not "we iterated." The specific decision: "We removed the desktop app and rebuilt entirely on WhatsApp."

Beat 4 — Where you are now (one sentence with a metric)

Current state, with one specific number that proves it is working. Retention, customer count, revenue — whichever is your strongest current signal.

Full example:

"We built a desktop inventory app first — launched in January with 5 beta users. Three of the five never opened it after the first week because the pharmacist's family member who manages stock does not use desktop applications. We scrapped the desktop product in week 4 and rebuilt on WhatsApp — zero installation, no login, text-based commands. We launched the WhatsApp version in March. We now have 23 paying customers at ₹64,400 MRR with 89% month-2 retention. The entire rebuild took 6 weeks."

That answer is under 60 seconds. It covers all four beats. It shows a real learning moment, a decisive response, and a specific outcome.

Pre-revenue / MVP stage

Partners ask this question expecting less at earlier stages — but not nothing. The honest pre-revenue answer acknowledges what you have, names what real users have done with it, and describes the most important thing you learned from that contact.

"We launched a WhatsApp prototype 4 weeks ago with 8 pharmacy owners we knew through our cofounder's network. None of them asked us to add features. Three of them gave us feedback on the expiry alert timing — they wanted 72-hour notice, not 48. We shipped that change in 2 days. Two of the eight asked us when they can pay. We are building the payment flow now."

That answer is more fundable than a polished product description from a founder who has not had real users touch the product yet.

Post-revenue stage

At this stage, the answer should center on the iterations that drove measurable metric changes — not just what features you added.

"We launched in January. Our first version required a 45-minute onboarding call with a founder. We had 8 customers after 6 weeks. In week 7, we shipped a self-serve WhatsApp onboarding flow that takes 5 minutes. In the 8 weeks since, we added 15 more customers without any founder-led onboarding calls. The onboarding change was the biggest single product decision we made — it changed our acquisition speed more than any marketing activity."

Product pivot stage

If you pivoted between your original concept and your current product, this question is your opportunity to demonstrate that the pivot was driven by evidence rather than impatience.

"We started building a desktop inventory app. After 6 weeks and 5 beta users, we had clear evidence that desktop was the wrong channel for our user — a family member managing stock on a phone who has never opened a business desktop application. We pivoted to WhatsApp-native in week 4. We shipped the WhatsApp version in week 10. That is the current product. The pivot was not comfortable — we scrapped 6 weeks of code — but the retention on the WhatsApp version is 89% at month 2 versus zero retention on the desktop version."

Speed benchmarks partners hold in their heads:

If your timeline and your output do not match these rough benchmarks, partners will probe the gap: "You've been working on this for 9 months — why are you still at 3 customers?"

The specific signals partners weight most:

• Shipped something to real users (not just built in isolation)
• Changed something based on what real users did (not based on internal opinion)
• Have a specific metric that proves the change worked (not just "users liked it better")

Mistake 1: Describing the product instead of the journey

The question is "what have you built so far" — not "what does your product do." Founders who answer with a product walkthrough have answered a different question. Partners can see the product. They want the story of how it got to its current state.

Mistake 2: Skipping the learning moment

An answer that covers version 1, version 2, and current metrics without mentioning what specific user behavior or feedback caused the change between versions misses the most important part. The learning moment — "three users never opened the desktop app" — is what makes the answer credible. Without it, the iteration story sounds like arbitrary product evolution.

Mistake 3: Not having a metric at the end

"We now have a much better product that users love" is not a metric. "89% month-2 retention across 23 customers" is. Every "what have you built so far" answer should end with a specific, credible metric that tells partners whether what you built is working.

Mistake 4: Over-explaining technical architecture

Partners are not usually evaluating technical architecture decisions in this answer — they are evaluating iteration speed and user-centricity. Unless your architecture choice is directly relevant to your competitive moat (which occasionally it is), skip the technical stack explanation and focus on what users did and what you changed.