To validate a startup idea before building it with AI tools, spend two weeks collecting evidence instead of code. In week one, interview people about the last time they had the problem. In week two, ask for a real commitment: a sign-up, a pilot or a payment. Build only if those signals clear a bar you set beforehand.

Picture a founder with an idea for a scheduling assistant for small physiotherapy clinics. On Friday evening they open an AI app builder. By Sunday there is a login screen, a calendar view and a booking flow that works in the demo. On Monday they send the link to clinic owners they know. The replies are warm ("looks great, keep me posted") and nobody signs up. The founder still doesn't know whether clinics feel this problem badly enough to change how they work.

Why validate a startup idea before you vibe-code it?

AI tools made building cheap, but they did not make it any cheaper to build the wrong thing. A working prototype answers "can this be built?" when the open question is usually "does anyone need this enough to switch?"

Vibe coding is building software by describing what you want to an AI tool in plain language and accepting the code it writes, often without reading it closely. It is a fast way to get something on screen. The trap is that a polished demo feels like progress, so founders skip the conversations that would tell them whether to keep going.

There is a second cost. Once an app exists, founders defend it, and it gets harder to hear that the problem is minor or the buyer is someone else.

We covered the general case in From Idea to Validation. This post turns it into a two-week plan for founders who could have a prototype by the weekend.

What should you decide before the two weeks start?

Decide what you are testing and what result would count as a pass, before you talk to anyone. Without a pass line written down in advance, every result can be read as encouraging.

Write the problem in one sentence

Name who has the problem, when it happens and what it costs them today. "Clinic owners lose bookings when patients cancel by phone after hours" can be tested. "Clinics need better scheduling" cannot.

List your riskiest assumptions

A riskiest assumption is the belief that, if wrong, would end the idea on its own. Typical ones are that the problem happens often, that the person who feels it can also buy a fix, and that current workarounds are painful enough to replace. Rank them and test the top two or three.

Set the pass line

A pass line is the result you agree, in advance, would justify building. Make it about behaviour, not opinion: people who agree to a follow-up call, who join a waitlist with their work email, who introduce you to the person who signs off on purchases, or who agree to pay for a pilot. Write it down and share it, so you can't quietly move it later.

What happens in week one of the validation test?

Week one is for interviews about past behaviour, not reactions to your idea. You are trying to learn how the problem shows up in people's lives today and what they already do about it.

Eric Migicovsky's Startup School lecture, summarised on the Y Combinator blog, names three common mistakes in user interviews: pitching the product, asking about hypotheticals and talking too much. He links these mistakes to Rob Fitzpatrick's book The Mom Test. His suggested questions include "tell me about the last time that you encountered this problem" and "what, if anything, have you done to try to solve this problem?"

The week-one plan, day by day

1. Day 1: Write the problem sentence, the riskiest assumptions and the pass line. Draft an interview guide built on past-tense questions.

2. Day 2: Make a list of people who match the user and the buyer. Send short, specific requests for a conversation, without describing your product.

3. Days 3 to 5: Run interviews. Ask about the last time the problem happened, what it cost, what they tried and who decided. Don't show the prototype. Take notes in their words.

4. Day 6: Keep interviewing until the answers start to repeat. Ask each person who else you should speak to.

5. Day 7: Sort your notes into patterns. Which problems came up without prompting? Which workarounds do people already pay for? Rewrite the problem sentence if the evidence points somewhere else.

What to listen for

• A specific recent story, not a general opinion.

• Money, time or staff already spent on a workaround.

• Frustration with the tools they use now.

• A clear answer to "who would approve buying something for this?"

What happens in week two?

Week two tests demand: whether people will do something that costs them a little time, reputation or money. Polite interest costs a customer nothing, so it tells you nothing about whether they will pay.

A demand test is any small experiment that asks a real person to take a real step toward using or buying your product. It can run before the product exists.

The week-two plan, day by day

1. Day 8: Choose one or two demand tests that match your riskiest assumption. A landing page tests whether the message makes people act. A pilot offer tests whether a buyer will commit.

2. Day 9: Build the test asset. A focused landing page with one call to action, a one-page pilot proposal, or a clickable prototype of the single core workflow. AI tools fit well here.

3. Days 10 to 12: Put the test in front of the people from week one and new people who match the same profile. Go back to interviewees with a concrete ask: join the pilot, introduce the decision-maker, or pay to reserve a place.

4. Day 13: If you built a prototype, watch two or three target users try the core task without help. Note where they get stuck and what they expected to happen.

5. Day 14: Compare the results with the pass line you wrote on day 1. Decide: build, revise or stop.

Two tests that work without a product

A smoke test is a landing page or ad for a product that doesn't exist yet, used to measure whether people try to sign up. Be honest on the page that it is early access or a waitlist.

A concierge test is delivering the outcome by hand to a few customers, so you learn what they value before you automate any of it.

How do you read the results: build, revise or stop?

Read the results against the pass line, not against how you feel about the idea. Stopping after two weeks is a good outcome: it saves the time and budget a full build would take.

• Specific stories, existing workarounds, and people taking the step you asked for. What it usually means: The problem is real and someone will act on it. Next step: Build the smallest version that delivers the core value.

• Real pain, but the person feeling it can't buy, or won't commit yet. What it usually means: Right problem, wrong buyer or wrong offer. Next step: Revise the buyer, the offer or the price and run week two again.

• Warm compliments, hypothetical "I would use that", no commitments. What it usually means: Interest without demand. Next step: Stop, or go back to week one with a different problem.

• Users can't complete the core task in the prototype. What it usually means: The idea may be sound but the workflow isn't clear. Next step: Fix the workflow before writing production code.

Signs you are reading the results too generously

• You are counting "sounds interesting" as a yes.

• The target user changed partway through, so the evidence is split across groups.

• The feature list got longer while the problem sentence stayed vague.

Why Product Discovery Should Happen Before Development covers the same decision point: discovery is done when there is enough evidence to decide, not when every question is answered.

Where do AI tools help during validation, and where do they mislead?

AI tools help most with the test assets and the note-taking, and mislead most when they stand in for real customers. Use them to move faster between conversations, not to replace them.

Where they help

• Drafting interview guides and outreach messages, which you then edit into your own voice.

• Building a landing page or a clickable prototype in a day for a week-two test.

• Grouping interview notes into themes, as long as you check each theme against the original notes.

Where they mislead

• Asking a chatbot whether your idea is good. It has no stake in your market and no memory of real buying decisions.

• Generating "synthetic users" to interview. They give plausible answers, which is the opposite of the surprise you need.

• Treating a prototype that works as proof the market wants it.

If you skip validation and build anyway, the problems tend to surface at launch. Your AI-Built App Works in the Demo. Here's What Breaks With Real Users covers the technical side of that.

How we approach it at Vizio AI

We treat validation as the first part of the build, not a separate project. Before writing production code, we work with the founder to pin down the problem sentence, the user and the buyer, and the assumptions that would end the idea if they turned out to be wrong.

We agree the pass line together and write it down. Then we help run the interviews and pick the demand test that fits the riskiest assumption, whether that is a landing page, a pilot proposal or a clickable prototype of one workflow. AI tools speed up that test material; the conversations stay with people.

At the end, we review the evidence against the pass line and recommend build, revise or stop. When the answer is build, the evidence sets the first scope: the first customer segment and the core workflow. This is the work behind our Venture Studio.

Sources

• Y Combinator Blog, Startup School Week 1 Recap: Kevin Hale and Eric Migicovsky: https://www.ycombinator.com/blog/startup-school-week-1-recap-kevin-hale-and-eric-migicovsky/

• Rob Fitzpatrick, The Mom Test: https://www.momtestbook.com/

• Vizio AI, From Idea to Validation: https://www.vizio.ai/resources/blog/from-idea-to-validation-what-should-happen-before-you-build

• Vizio AI, Why Product Discovery Should Happen Before Development: https://www.vizio.ai/resources/blog/why-product-discovery-should-happen-before-development

• Vizio AI, Venture Studio: https://www.vizio.ai/studios/venture-studio