How to Validate a Startup Idea Before You Build

A working prototype used to be evidence. It proved a team could ship, and shipping was hard enough that the proof meant something. That filter is gone. A coding agent will now produce a convincing version of almost any idea you describe, including the bad ones, which means "we built it" no longer tells you anything about whether it should exist.

Y Combinator named the consequence in its request for startups on product discovery: "writing code is only part of building a product people want. The most important part is figuring out what to build in the first place." And the reason this is suddenly urgent rather than evergreen advice: "As agents increasingly take the first pass at implementation, the way we define and communicate what to build needs to change."

Garry Tan, president and CEO of Y Combinator, built something concrete for that gap. In a YC video on running coding agents as a team, he demonstrates gstack, his open-source set of Claude Code skills, and the first skill he reaches for is not a build command. It is office hours. "It's actually modeled exactly after what we go through at YC as a partner doing office hours with startups," he says. "It starts by asking six forcing questions for you to reframe your product before you start building."

That is a validation gate, and it is the most useful one a founder can run this week, because it costs one conversation and it runs inside the same tool that would otherwise have spent the afternoon building the wrong thing.

Why validation became the expensive step

The old sequence put the hard filter in the middle. You had an idea, you spent three months and real money building it, and the build itself killed most bad ideas by exhausting the team before launch. That was wasteful, but it was a filter.

Now the build costs an afternoon, and the filter is gone with the cost. Tan is direct about what the agent does with an unexamined idea. Describe what you want and "it'll go do that. It will just literally do it, but it won't think about who's the user, what is the business model, who wants this, what's the pain point."

So the gate has to move upstream, to the only step that is still expensive: deciding. This is the same conclusion the Pylon founders reached the slow way. Pylon, now a B2B AI customer support platform, pivoted through several ideas before landing on the one that worked, and told YC's Root Access what the first failure taught them: "we learned to not build something before we have very clear validation." After that, "for each successive idea we just refined our process for how to validate an idea." The process was the asset, not any individual idea.

The six forcing questions

The questions below are the current definition in the office-hours skill in Tan's gstack repo, in its office-hours/sections/phase-2a-startup-diagnostic.md file, paraphrased, with what each one is actually testing. The design principle running through all six is that a comfortable answer means you have not gone deep enough.

1. Demand reality. What is the strongest evidence that someone actually wants this? Not that they find it interesting, not that they signed up for a waitlist, but that they would be genuinely upset if it disappeared tomorrow. In the demo the skill opens with the question it treats as decisive: "Here's the question that determines everything else. What's the strongest evidence that you have that someone actually wants this?" Tan's own framing is that it is "one of the most important questions to ask yourself." What passes is behavior. Someone paying. Someone expanding usage. Someone building their workflow around it. Someone who would have to scramble if you vanished. What fails is opinion, waitlist numbers, and investor enthusiasm about the category, because none of those cost the person anything.

2. Status quo. What are your users doing right now to solve this problem, even badly, and what does the workaround cost them? A real problem almost always has an ugly workaround attached, and the workaround is measurable: hours per week, dollars wasted, tools duct-taped together, a person hired to do it by hand. The red flag here is the answer founders think is their strongest card, that nothing exists yet and that is why the opportunity is so big. If nobody is doing anything about the problem today, the likeliest reading is that it does not hurt enough to act on. This is also where latent demand is worth separating from no demand: unavailable, unaffordable and unknown are three different diagnoses with three different fixes.

3. Desperate specificity. Name the actual human who needs this most. Their title, what gets them promoted, what gets them fired, what keeps them up at night. Category answers fail: healthcare enterprises, SMBs, marketing teams are filters rather than people. The skill's line for this is the one worth taping to a wall: "You can't email a category." If you cannot name a person, you do not know who you are building for, which is the same discipline as writing a real ideal customer profile rather than a demographic sketch.

4. Narrowest wedge. What is the smallest possible version of this that someone would pay real money for this week, not after you build the platform? The answer should be describable in days: one feature, one workflow, sometimes a weekly email or a single automation. The warning sign is the claim that the full platform must exist before anyone can really use it, which usually means attachment to the architecture rather than to the value. Pylon is the worked example. Its first product was a narrow layer for managing, prioritizing and routing the B2B support conversations companies were already having in Slack, as TechCrunch described it at launch, creating tickets in tools like Zendesk only when that made sense. The full AI support platform came later, after the customers were real.

5. Observation and surprise. Have you sat down and watched someone use this without helping them, and what did they do that surprised you? If nothing surprised you, you were either not watching or not paying attention. Surveys and demo calls do not count: a survey records what people say, and a demo is a performance you are running. The most valuable observation is a user doing something the product was not designed for, which is frequently the real product trying to emerge. This question is the one that genuinely resists automation, though AI market research can get you to the right narrow segment faster so the humans you watch are the right humans.

6. Future fit. If the world looks meaningfully different in three years, and it will, does your product become more essential or less? What passes is a specific claim about how your users' world changes and why that change makes you more valuable. What fails is the rising-tide argument every competitor can also make, that the market is growing or that AI keeps getting better so you keep getting better. Growth rate is not a vision.

Which questions your stage actually needs

The skill does not ask all six every time, and the routing is worth stealing even if you never install it. Pre-product, it asks the first three: demand, status quo, and the specific human. Once you have users, it asks status quo, wedge, and observation, because the evidence is now sitting in your own product and most founders are not looking at it. Once you have paying customers, it asks wedge, observation and future fit, since demand is settled and the risk has moved to expansion and durability. For pure infrastructure work, it asks only status quo and wedge.

The useful implication is that validation is not one event before the company starts. It is a different set of two or three questions at each stage, and the questions get harder rather than easier as evidence accumulates.

Watch the gate work on a real idea

The demo is more instructive than the question list, because it shows the gate doing the thing a list cannot: pushing back.

Tan brings a genuine annoyance as the idea. Pull all of his 1099 tax forms out of Gmail and his bank portals automatically, since some institutions email the documents and some do not. He answers the demand question with his own experience of hunting the forms down. The skill does not accept it: "Okay, the pain is real, but the consequence is friction and annoyance, not actual penalties."

That distinction is the whole of question one. A real pain that carries no consequence does not convert, because nobody reorganizes their year around an annoyance. Tan pushes back with the consequence he actually has, which is an accountant sending him irritated emails and phone calls, and the conversation moves on.

Then the incumbent question, which is where most ideas quietly die: "TurboTax and H&R Block actually have 1099 import features and Plaid connects to banks. Why aren't those solving it for you?" If you cannot answer that, you are not describing a startup, you are describing a feature request for a company that already has distribution.

The most valuable turn comes next, and it goes in the direction founders do not expect. The skill reads the idea as bigger than it was pitched: the user is "thinking bigger than a document aggregator. They're seeing this as a funnel. The hook is we'll find all your 1099s for you, solving an immediate pain, but the expansion is now that you have your docs, let's actually get your taxes prepared, which is matchmaking and lead gen for tax preparers." The skill calls it "a classic wedge strategy" and "actually a more interesting business model than just the document aggregation alone." Tan's verdict on that read is "which is right," and he does the arithmetic out loud: document aggregation might support "two or five dollars a month or two or five dollars maybe an entire year," while a cut of the tax preparation transaction "might be 10x more."

Notice what happened. The gate did not narrow the idea, which is the stereotype of what a skeptical advisor does. It found the wedge, then attached to the far end of it a business Tan guessed might be worth an order of magnitude more. Validation that only ever shrinks ideas is just pessimism with a checklist.

Force three approaches, then choose on effort and risk

After the questions, the skill produces two or three ways to build the thing rather than one, three in this demo, each with its effort and risk named. In the demo: a small-effort, small-risk version using Gmail authentication and a bank checklist with no browser automation initially; a full version with browser automation and a CPA marketplace; and a third that flips the go-to-market and starts from the accountants.

Tan's reaction to the safe option is the part worth copying: "that sounds interesting, but it doesn't sound big enough for me to actually even work on this. Like, I could do that myself." He picks the ambitious one, "This sounds like what I want, actually," then improves it in a direction the model had not proposed, extending the browser automation to Gmail itself so the OAuth integration disappears.

Three named options with effort and risk attached is a better decision format than one recommendation, because it makes the tradeoff explicit and it gives you something to argue with. The approach he landed on was, in his words, "a very out of pocket sort of unusual way to solve this problem," and he credits the coding models for making anyone try it at all: "You're able to have an idea and then get farther along with it than you ever would be."

A gate that never kills anything is not a gate

Here is the number that makes this credible. Tan says that "maybe one in three times" he runs office hours on an idea, he reaches the end and concludes "this isn't something that makes sense."

That kill rate is the whole value. A validation process that approves everything you bring it is a confidence generator, not a filter, and most founder-facing AI tools are tuned to be exactly that. If you run this gate on five ideas and all five survive, the gate is broken, or you are answering comfortably, or you are bringing only ideas you have already decided to build.

He is also honest about the ceiling. The skill is "a distilled down 10% strength version of what we do at YC every day," and about the demo idea he says plainly: "I'm not saying this is actually a good startup idea, but you can see how this got farther along." Ten percent of a YC partner, available at midnight, at the moment you have the idea, is a real tool. It is not a verdict.

Run the interrogation in the tool that will build it

The structural reason this works better than a document is that the gate lives where the work happens. The output of office hours is not advice you have to remember. It is the plan the agent then executes, so the reframing survives into the build instead of evaporating between the conversation and the keyboard.

The same session also runs an adversarial pass over the resulting plan, which is the second half of the discipline. Tan describes it as a multi-step adversarial review that finds problems and fixes what it can: no failure handling, no privacy section, no proposed solution for the two-factor handoff. In the demo, "our doc survived two rounds of adversarial review and it automatically caught and fixed 16 issues," moving the plan's own score from six out of ten to eight out of ten with three issues deliberately deferred.

Two things about that are worth separating. Catching a missing privacy section before the code exists is exactly where that work belongs, and it is cheap there and expensive later. But an agent scoring its own plan eight out of ten is not external validation of anything, any more than its approval of your idea was. It is a completeness check on the document.

The security instinct in the same video is the one I would underline for anyone adopting a stack of community skills, since this is where the CISSP in me gets nervous. Tan notes that "one of the things that's been really scary in AI coding right now is supply chain attacks," and he says he is really, really paranoid about it. A validation gate assembled from skills you did not write is still code running with your credentials in your repository. Read what you install, pin it, and keep the review human on anything that touches a secret. The same rule applies to the AI prototyping that follows: a prototype is a throwaway until it has been rebuilt and reviewed.

Where the gate stops being enough

The honest limit is simple, and it is the thing the growing category of AI idea-validator tools obscures: a model cannot answer question one for you.

It has never met your customer. It has no access to whether anyone will pay. What it can do, and does genuinely well, is refuse to let you skip the question, name the assumption you smuggled in as a fact, separate a real pain from an expensive one, and propose a wedge narrower and a business larger than the one you walked in with. That is a good adversary. It is not demand evidence, and an agent that agrees with your idea has told you only that your pitch is internally consistent.

So the gate has two halves, and only one of them is automated. The model runs the interrogation. You go get the answer to question one from a person who is not in the conversation, which still means talking to users, in the style The Mom Test describes, and then watching one of them use the thing without your help. If you are still upstream of all this and looking for the idea itself, that is a different problem with a different method: how founders actually come up with startup ideas covers where the ideas come from, and this gate is what you run on one once you have it.

Both halves are part of the same shift this site is about, which is that AI changes which parts of company-building are expensive rather than making all of them cheap. Building moved to nearly free. Judgment did not.

What to do this week

1. Take the idea you are closest to building and answer question one in writing, in one paragraph, naming the specific person and the specific behavior. If the paragraph contains the words interested, excited, or waitlist, you do not have an answer yet.
2. Run the other five questions as a conversation, not a form, in whichever coding tool you already use. Install gstack if you want Tan's exact version, or paste the six questions and instruct the model to ask them one at a time and to push until each answer is specific. Do not let it move on when you give it a comfortable answer.
3. Write down the approaches it proposes with effort and risk attached, and pick deliberately. If the safe one does not feel big enough to be worth your year, that is information.
4. Separate the pain from the consequence for your own idea in one sentence each. If the consequence is only friction, find the version where someone gets fired, fined, or outcompeted, or drop the idea.
5. Get the one answer no agent can give you. Book two conversations with the named human from step one, ask about what they do today rather than about your idea, and watch one of them work without helping.
6. Before you install anyone's skill pack, read it. It runs with your credentials in your repository.

If you want the whole operating system around this, from choosing the job to shipping with agents, that is what AI Operating System for Startups is built to teach.

The barrier Tan describes is real: "The barrier to building just collapsed." The question that survives it is the one YC has been asking since long before any of this, and he closes on it. "Go make something people want."

Sources

• How to Make Claude Code Your AI Engineering Team (Y Combinator), the video this article distills, where Garry Tan demonstrates the office-hours skill and runs it on a real idea.
• gstack, Tan's open-source Claude Code skill set, including the office-hours skill whose current diagnostic file defines the six forcing questions paraphrased here.
• Garry Tan's profile at Y Combinator and Wikipedia, for his current role and his background as a Posterous co-founder and early Palantir employee.
• Request for Startups: Cursor for Product Managers (Y Combinator), for the argument that figuring out what to build is the part agents have not taken over.
• Rebuilding Customer Support for the AI Era (YC Root Access), where Pylon's co-founders describe learning not to build before they had clear validation, and refining a validation process across each idea.
• Pylon wants to make it easier to manage B2B conversations in Slack (TechCrunch), for the narrow first product that preceded the platform.