ValidationJuly 9, 2026By Maarten Follaets

How to validate an idea without building an MVP

A heavy MVP box on one side and four light no code tests on the other, with a scale tipping toward the lighter tests

Quick answer: You can validate an idea without building an MVP by running no code demand tests first. Put up a smoke test landing page, try a fake door, do a concierge version by hand, and make one real pre sale. Each takes days and tells you whether people actually want the thing. It matters because the top reason startups fail is weak demand: in CB Insights' analysis of why startups fail, no market need and poor product-market fit sit at the top of the list. An MVP does not lower that risk. Testing demand before you build does.

Everyone treats the MVP like the first honest step. Build the smallest version, ship it, see if people use it.

I get the appeal. But an MVP is still a product. It still takes months, it still needs marketing before anyone touches it, and at the end it only tells you whether the few people who found it liked it. That is a slow, expensive way to ask a question you can answer this week.

So here is what I run before I build anything.

Test the demand, not the product

The MVP is trying to learn one thing: does anyone want this. You can learn that without the product.

The trick is to test the promise instead of the machine. People do not care how you built it. They care whether the thing you are offering solves a problem they actually have, badly enough to do something about it. Every test below puts that promise in front of real people and watches what they do.

None of them need a codebase. All of them give you a signal in days.

Five no code tests I actually use

The smoke test landing page. One page that describes the product as if it already exists, with a single call to action: join the waitlist, request access, pre order. Send real, targeted traffic to it and measure the conversion. If a few hundred of the right visitors barely click, the promise is not landing. If a healthy share commit their email or their money, you have something.

The fake door. Inside an existing surface, a newsletter, a small community, your own site, add a button for the feature you are considering. When people click, they hit a short "we are building this, want in" screen. The click rate is a clean demand vote, and nobody had to build the feature to cast it.

The concierge. Do the thing manually, for a handful of real customers, before automating any of it. If you are imagining a meal planning app, plan a few peoples' meals by hand over a week. You learn what actually matters, and you find out whether people value the outcome enough to keep showing up.

The Wizard of Oz. Like the concierge, but the customer thinks it is automated while you are the machine behind the curtain. It is the fastest way to test a product experience without engineering the product.

The pre sale. The strongest signal there is. Ask for money, a deposit, or a paid pilot before the thing exists. It feels uncomfortable, which is exactly why it works. People are polite with their words and honest with their wallets.

I go deeper on that last point in how to test willingness to pay, because a signup and a payment are very different promises.

Read the behaviour, not the words

Every one of these tests produces two kinds of data: what people say, and what people do. Only one of them is worth anything.

Someone can tell you the landing page is brilliant and never sign up. Someone can pick apart your mockup and then pre order. Watch the action. A committed email, a deposit, a booked call, an hour of someone's time. Those are votes. "I love this, you should build it" is applause, and applause does not pay rent.

This is the whole reason no market need keeps killing startups. Founders do not build the wrong thing out of laziness. They build it because building felt safer than asking a stranger to commit. I wrote about that failure mode in how to avoid building something nobody wants.

When the MVP finally makes sense

None of this means MVPs are bad. It means the MVP is the second question, not the first.

Once a smoke test converts, once people pre order, once the concierge version has people coming back, you have earned the build. Now the MVP is answering a real question, how do we deliver this well, instead of a hopeful one, will anyone care. You are building from evidence, and you know a lot more about what to build.

That is the difference. Not building versus validating. Building after proof versus building on hope.

Where Ventropolis fits

I built Ventropolis because running this loop well takes more discipline than I always have on my own.

Foxy, our AI co-founder, helps you name the one assumption that has to be true, pick the cheapest test that could break it, and read the results without flattering yourself. It keeps you honest about the difference between a compliment and a signal, so you do not talk yourself into a build you have not earned.

You still do the work. You just do it before the expensive part.

If you want to run your first no code validation loop with an AI co-founder in your corner, see how Ventropolis works for founders.

So before you scope that MVP, can you get ten strangers to take one small committing action when the idea is still just a page?

Frequently asked questions

Can you really validate an idea without building an MVP?

Yes. An MVP answers one question, will the people who find my product use it, and it takes months to ask. The cheaper tests answer the earlier question, does anyone want this at all. A landing page, a fake door, a concierge run, and a real ask each give you a demand signal in days, without product code. Build the MVP after those pass, not to find out whether they will.

What is a smoke test landing page?

It is a single page that describes the thing as if it exists, with one clear call to action like join the waitlist or pre order. You send real traffic to it and measure what share of visitors take that action. It tests whether the promise is compelling enough to make a stranger commit, which is the thing an MVP is trying to learn anyway, minus the build.

How much traffic or how many people do I need?

Enough that the result is not a coin flip. For a landing page, a few hundred targeted visitors will show you whether conversion is a rounding error or a real signal. For conversations, aim for around ten people who actually have the problem. You are not after statistical certainty, you are after a clear yes or a clear no from people who are not your friends.

What counts as a real validation signal?

Behaviour that costs the person something: a signup with a real email, a pre order, a deposit, a paid pilot, an hour of their calendar. Compliments do not count. If nobody will take one small committing action when the thing is still just a page or a mockup, that is useful information, not failure.

When should I actually build the MVP then?

When a no code test has already given you a demand signal you believe, and building is now the cheapest way to learn the next thing. At that point the MVP is answering a real question about how, not a hopeful question about whether. You build from evidence instead of from the fear of asking.