ValidationAugust 6, 2026By Maarten Follaets

How to validate a startup idea before building it

Cover reading There are no facts inside your building, with a callout quoting Steve Blank that no business plan survives first contact with customers, and the Foxy mascot in the corner

Quick answer: Validating a startup idea before building means proving that the problem is real and that people will pay to solve it, using cheap tests with real customers, before you write meaningful code. You do it because building is the single most expensive way to test an assumption. Steve Blank's rule is blunt: there are no facts inside your building, so get outside. Talk to the people you think have the problem, watch what they actually do, and ask for a small commitment. If the belief your idea rests on survives contact with customers, you have earned the right to build. If it does not, you just saved yourself months.

There is a version of you, right now, itching to open the code editor.

Resist it for one more week. That week is the cheapest insurance you will ever buy.

Building is the most expensive test you can run

Every startup idea is a bet on a belief: that a specific group of people have a problem bad enough to pay for a fix. You can test that belief in a lot of ways. Building the product is the slowest and most expensive one on the list.

Think about what a build actually costs. Weeks or months of your time. Design, code, infrastructure, maybe a hire. And the worst cost is hidden: once you have built it, you are attached to it, so you interpret every lukewarm signal as encouragement. Sunk cost quietly becomes sunk judgement.

So building first does not just risk your money. It risks your honesty.

The cheaper the test, the faster you learn, which is the whole case for validating an idea without building an MVP.

Get out of the building

The most useful sentence in startups was written by Steve Blank, who turned it into a method called customer development. In his customer development manifesto he puts it plainly: there are no facts inside your building, so get outside. He pairs it with a second line that every founder should tape to the wall: no business plan survives first contact with customers.

Read those together and the instruction is obvious. The answers you need are not in your head, your notes, or your spreadsheet. They are out there, with the people who supposedly have the problem. Your job before building is to go and collect them.

That does not mean asking people if they like your idea. It means watching what they do now, what it costs them, and whether they will commit to a different way. Opinions live inside the building. Facts live outside it.

What "validated before building" actually looks like

Here is the sequence I try to run before writing code that matters.

First, name the one belief the idea depends on, in a sentence you could be wrong about. Not "there's a market for this" but "freelance designers lose a day a week chasing invoices and will pay to stop." Now it is testable.

Second, go and test that sentence with real people. Ten honest conversations about what they do today beats a hundred survey clicks. If you are not sure how to run those without leading people to the answer you want, that is its own skill worth getting right.

Third, ask for a commitment that costs something. A deposit, a pre-order, a slot on their calendar, a signed intent to buy. A yes that costs nothing proves nothing.

Fourth, decide in advance what a no looks like, and be willing to hear it. Write the fail line down before you run the test, while you can still be honest with yourself.

This is not my first company. I have taken one all the way to a sale, a good outcome with more luck in it than I like to admit, and even then the pull to just build was constant. Deliberate validation is the discipline I wish I had trusted earlier, because the alternative is finding out in month six.

A quick picture

Imagine you want to build a tool that helps small e-commerce shops forecast stock.

The tempting move is to build the forecasting engine, because that is the interesting part. But the engine is not the risk. The risk is the sentence "shop owners are losing enough money to bad stock guesses that they will pay for software to fix it." If that is false, the cleverest engine in the world dies unused.

So the first week is not code. It is calls to shop owners about what they lost last time they over-ordered or sold out, what they use to plan now, and whether they will put a deposit on something better. Cheap to run. And it can absolutely come back no, which is exactly why it is worth running. Skipping this step is a big part of why startups fail: the thing gets built before anyone checks that people wanted it.

Where Foxy fits

The hard part is not knowing you should validate first. Everyone nods at that. The hard part is being honest with yourself when the signal is weak, because you are the person who most wants the idea to be right.

That is the gap we are building Foxy to fill. It is an AI co-founder whose job is to stay unattached to your idea: to read what customers actually said and did, and tell you whether the belief your idea rests on really held, or whether you are about to build on a polite yes. If you want that objective second read before you commit the months, start here.

So here is the question to sit with before you open the editor. What is the one thing that has to be true for this idea to work, and have you left the building to check it yet?

Frequently asked questions

What does it mean to validate an idea before building?

It means proving the problem is real and that people will pay to solve it, using cheap tests with actual customers, before you write meaningful code. You are trying to fail on paper instead of failing after six months of building, when it is expensive and slow to change course.

Why not just build a quick version and see?

Because building is the single most expensive way to test an assumption. Code, design, and your own time are costly and slow to undo. If the belief your idea rests on is wrong, a landing page or ten conversations reveal it in a week. An MVP reveals it in a season, after you have paid for it.

What should I test before building?

The load-bearing belief: that the problem is real, frequent, and painful enough that people already try to solve it, and that they will part with money or real effort for a better fix. If that survives contact with customers, you have earned the right to build. If it does not, no amount of code saves it.

How do I validate without writing code?

Get out of the building. Talk to the people you think have the problem, watch what they do today, and ask for a small commitment: a deposit, a pre-order, a signed letter of intent, an hour of their week. Landing pages, mockups, and fake doors all test demand before a product exists.

How long should pre-build validation take?

Usually days to a few weeks, not months. The point is speed and cost, not perfection. You are looking for a clear signal on one belief at a time, then deciding whether to keep going. If validation is dragging on for months, you are probably avoiding a no.

What if customers say they love it but I still worry?

Then you have not tested the right thing yet. Words are cheap. Look for behaviour that costs them something: money down, time booked, a switch away from what they use now. A commitment is worth a hundred compliments, and it is the only signal worth building on.