ValidationJune 26, 2026By Maarten Follaets

A step-by-step startup idea validation framework (the one I wish I'd followed)

Quick answer: A startup idea validation framework is a fixed sequence you run before building, so you test the idea on purpose instead of hoping. The five steps I follow: (1) write down every assumption your idea depends on, (2) rank them and pick the riskiest, (3) design one cheap test for that single assumption, (4) run it on about ten people outside your circle, (5) read the result against a threshold you set in advance, then turn the loop again on the next assumption. One turn takes two to four weeks, needs no MVP, and you can do it while still employed.

I've built and sold a startup before. I'm proud of it, but if I'm honest, I was figuring a lot of it out as I went, and some of it was luck. This time I want to validate deliberately instead of trusting my gut. So I went looking for a clean framework I could actually follow, and most of what I found was a pile of tips with no order. Talk to users. Build an MVP. Iterate. Sure. In what order? Starting where? Stopping when?

A framework is supposed to answer exactly those questions. Here is the one I use now.

Why a sequence beats a pile of tips

The most common reason startups die is not a weak team or bad code. It's building something nobody needed. CB Insights' research on why startups fail puts "no market need" at the top of the list, around 35% of failures. Almost all of those founders could build. What they skipped was checking, in the right order, whether anyone wanted it.

That's what a framework fixes. It forces you to test the thing that can kill the idea first, while the test is still cheap. We named ours the Validation Loop because the steps repeat, but you can run the same five steps on a whiteboard.

Step 1: Write down your assumptions

Your idea is not one bet. It's a stack of them. People have this problem. They feel it often enough to care. They'll pay to fix it. You can reach them affordably. Your solution is the one they'll choose.

Write every one of those beliefs down as a plain sentence. Most founders never do this, which is why they end up defending the whole idea at once instead of testing one piece. You can't validate a feeling. You can validate a list.

Step 2: Rank them and pick the riskiest

Now sort the list. For each assumption ask two questions: how dead is the idea if this is wrong, and how little do I actually know about it? The one that scores high on both is your riskiest assumption, and it's where you start.

For most early ideas it's not "can I build this". It's "will anyone pay". Founders love starting with the part they enjoy, usually building, because it feels like progress. The framework drags you back to the scary question first, on purpose.

Step 3: Design one cheap test

One assumption, one test. Resist the urge to test five things at once. If your riskiest assumption is that people will pay, your test is not an MVP. It's a conversation, a landing page with a real "I want this" button, and a direct ask for something that costs the other person.

Decide the threshold before you run it. Something like: out of ten target customers, at least three pre-pay, put down a deposit, or sign a letter of intent. Writing the number down in advance is the part that keeps you honest later.

Step 4: Run it on people outside your circle

This is where most validation quietly fails. Friends, family, and people who like you are kind. Their encouragement feels like proof and isn't. You need people who have nothing to gain from being nice to you.

Find about ten people who genuinely have the problem. Ask how they handle it today instead of pitching. Put the landing page in front of them. Then make the real ask and watch what they do, not what they say. Rob Fitzpatrick's The Mom Test is the best short read on how to do this without leading the witness.

Step 5: Read the result, then turn the loop

Hold the result against the threshold you set in Step 3. Did enough strangers commit something real? If yes, that assumption is validated. Mark it, then go back to Step 2 and run the loop on the next riskiest one. Validation is not a single yes. It's a stack of bets, knocked down in order.

If the answer is no, you have not failed. You've spent a few weeks instead of a year to learn that this version doesn't hold. Usually the underlying problem is real and only the solution was off, so you adjust and run the loop again. That's the whole point of doing it before you build.

What you're left with

Run a few turns and you stop having opinions about your idea and start having evidence. A list of assumptions, each marked validated, invalidated, or still open, with the proof attached. That's worth more than confidence, and it's the thing an investor, or a future you about to quit a job, can actually trust.

If you'd rather run this with structure than improvise it on a whiteboard, that's exactly what we built Ventropolis for. You can see how the Validation Loop works or start validating your idea.

So before you open a code editor, one question. What's the single assumption that, if it's wrong, makes the rest of the plan pointless, and have you actually tested it yet?

Frequently asked questions

What is a startup idea validation framework?

It's a fixed sequence you run before building, so you're testing your idea on purpose instead of guessing. The version I use has five steps: write down your assumptions, rank the riskiest one, design one cheap test for it, run it on people outside your circle, then read the result honestly and turn the loop again. The point is the order. Most founders do these things randomly, or skip straight to building. A framework just makes sure you test the thing that can kill the idea first.

How long does it take to validate a startup idea this way?

One turn of the loop usually takes two to four weeks, and you can do it while keeping your job. You are not building anything. You need a few hours a week for around ten conversations, one simple landing page, and one direct ask. The slow part is reaching real customers, not the framework itself.

Do I need to build an MVP to validate my idea?

No, and building one first is usually the expensive mistake. An MVP answers 'can we build it', which is rarely the risky question. The risky question is 'will anyone pay'. You can test that with conversations, a landing page, and a real ask before you write any code. Build only after the evidence says someone wants it.

What's the riskiest assumption, and how do I find mine?

Your riskiest assumption is the belief that, if it's wrong, the whole idea falls apart, and that you currently have the least evidence for. For most early ideas it's 'people will pay for this', not 'I can build it'. List every belief your idea depends on, then sort by 'how dead is this if I'm wrong' times 'how unsure am I'. The top of that list is where you start.

When is an idea actually validated?

When people who don't know you do something that costs them, money, time, or a signature, to get your solution. Stated interest doesn't count. Set a threshold before you run the test, for example 'three of ten people pre-pay or sign a letter of intent', so you can't move the goalposts afterward. If you hit it, the assumption is validated and you move to the next one. If you don't, you've learned that cheaply.