How to Validate a Startup Idea When Building Is Cheap

When building a product took six months and a team, founders validated ideas because they had to. Nobody wanted to spend half a year on something nobody wanted.

Now you can build a working app in a weekend, so many people skip validation entirely. The prototype becomes the test: build it, launch it, see what happens. When nothing happens, they build the next one.

The problem is that a working prototype proves exactly one thing: that it can be built. That was never really in doubt. What it doesn't prove is that a specific group of people has the problem badly enough to change their behavior, or pay, to solve it.

Cheap building should make validation easier, not optional. Here's how I'd do it.

What validation actually means

You've validated an idea when you have evidence, not opinions, that:

1. A specific group of people has the problem. You can name them and find them.
2. It's painful enough that they're already trying to solve it. They use workarounds, spreadsheets, paid tools or people.
3. They'll commit something to solve it better. Money, a pre-order, time on a call, or access to their data.

Compliments aren't evidence. "I'd totally use that" isn't evidence. Signups from friends aren't evidence. Commitment is.

A two-week validation plan

Days 1–2: Write the hypothesis down

One sentence, in this shape:

[Specific people] struggle with [problem], currently deal with it by [workaround], and would pay for [outcome].

Then write your kill criteria before you start, while you're still objective. For example: "If fewer than 3 of 10 interviewees describe this as a top-three problem, I stop." Founders who skip this step always find a reason to keep going.

Days 2–7: Talk to ten people who have the problem

Not friends, and not people who'll be polite. Find them where they talk about the problem: communities, forums, LinkedIn, Reddit. Ask for 20 minutes to learn how they handle it today.

The best guide to these conversations is Rob Fitzpatrick's book The Mom Test. The core rules:

• Ask about the past, not the future. "When did this last happen? What did you do?" not "Would you use an app that…?"
• Don't pitch. The moment you describe your idea, people start being nice to you.
• Follow the money and the time. "What have you tried? What did it cost? Why did you stop using it?"

You're listening for two things: how often the problem happens and what it costs them. A daily problem that costs real money is a business. A yearly annoyance usually isn't.

Days 7–10: Run a smoke test with a price on it

This is where AI tools earn their keep. In one afternoon you can build a landing page that describes the outcome, shows the price, and has a single call to action: join the waitlist, book a demo, or pre-order.

Put the price on the page. A waitlist without a price tells you people are curious. A waitlist with a price tells you people are interested at that price.

Then send real traffic: post where your audience gathers, message the people you interviewed, or run a small ad test. A few hundred visits from the right audience is enough to see a signal. Track how many visitors take the action, and email every signup to ask why they did.

Days 10–14: Pre-sell or deliver it by hand

The strongest validation is someone paying before the product exists.

• Pre-sell: offer a discounted founding price to the people who signed up or said the problem was painful.
• Concierge test: deliver the outcome manually, using spreadsheets, existing tools and your own time, for a few customers. If they won't pay for the result done by hand, automating it won't change their mind.

Day 14: Decide

Compare what happened with the kill criteria you wrote on day one. Then make one of three calls:

• Build: people have the problem, it's painful, and some committed. Build the smallest version that delivers the outcome they paid for.
• Pivot: the problem is real, but your solution or audience is wrong. Adjust the hypothesis and run another two weeks.
• Stop: nobody cared enough. You lost two weeks, not six months. That's the win.

Signals that lie

Watch out for these. They feel like validation and aren't:

• Compliments and enthusiasm. Pleasant, free and meaningless.
• "Send it to me when it's ready." A polite exit.
• Launch-day spikes. Curiosity isn't demand.
• Big waitlists with no price. People join lists for free.
• Signups from your own network. They're supporting you, not the product.

Use AI to validate, not just to build

The same tools that let you build fast make validation much cheaper:

• Landing pages and pricing pages in an afternoon.
• Clickable demos to show in interviews, without building the real thing.
• Summarizing interview notes to spot patterns across conversations.
• Drafting outreach messages. Personalize every one before sending.

The mistake isn't using AI to build. It's building the full product when a landing page and ten conversations would have answered the question.

After validation

Once you build, the work shifts to the two things that decide whether the product survives: getting your first 100 users and making sure they get enough value to pay for it. And if you're wondering how to budget the build itself, here's what it really costs to build an app with AI.