The most expensive way to test an idea is to build it. Yet that is exactly what most first-time founders do: raise or spend a chunk of money, disappear for four months, launch, and only then discover whether anyone wants the thing. There is a better order. You can test an MVP with no code at all, prove that people actually want it, and only then pay to build it properly. This guide walks through the two methods we recommend most, concierge and Wizard of Oz, and how to run them yourself before you commit a development budget.
Why test an MVP with no code first
The point of an MVP is to learn something, not to have something. And the thing you most need to learn early, whether anyone will actually use and pay for your idea, does not require a finished app to answer. It requires putting the core promise in front of real people and watching what they do.
Building first inverts the risk. You spend the most money at the moment you know the least. Testing an MVP with no code flips that around: you spend almost nothing while uncertainty is highest, and you only open the budget once you have evidence. We put real numbers on what that budget looks like in what an MVP really costs in the UK in 2026, and the whole reason to test first is to make sure that money goes towards something people want.
Method 1: the concierge MVP
A concierge MVP means you deliver the service your app would eventually automate, but you do it manually, by hand, for a small number of real users. No app exists. You are the app.
Say your idea is an app that builds personalised weekly meal plans. The concierge version is simple: you find five people, ask them the questions your app would ask, and email them a meal plan you made yourself in a spreadsheet. No code, no product, just the actual value delivered by hand. What you learn is enormous. Do people want this enough to give you their details? Do they use the plan once they have it? Do they come back next week? Would they pay?
The magic of the concierge approach is that it tests the value, not the interface. If people will not engage when you hand them the result personally, a slick app will not save the idea, it will just make the failure more expensive. And if they love it, you now know exactly what the product needs to do, because you have done it by hand and felt where the effort really is.
Run it for two or three weeks with a handful of people. Charge them something if you can, even a small amount, because nothing tests real demand like asking for money. The signal from five people who pay is worth more than a thousand who click “interested”.
Method 2: the Wizard of Oz MVP
The Wizard of Oz method goes one step further in the illusion. Here the user sees what looks like a working product, but behind the scenes a human, usually you, is doing the work the software would eventually do. The user does not know. Like the man behind the curtain, you are pulling the levers by hand.
In practice this often looks like a simple front end with no real engine behind it. The user submits a request through a basic form or a no code tool, and instead of an algorithm processing it, you do, and you send back the result so quickly it feels automated. The classic example is the online shop that was really one person taking orders and buying the items manually to see if anyone would buy computers online at all. They would.
Wizard of Oz is the right choice when the interface itself is part of what you need to test, or when the “magic” of your product is a process you can fake convincingly before you build it. It costs a little more effort than a concierge test because you have to create the appearance of a product, but you can build that appearance with no code using off-the-shelf form and automation tools. You are still not writing the real thing.
How to run either test in practice
Both methods follow the same shape, and you can run either in a couple of weeks. Here is the sequence we use.
Start by writing down the single riskiest assumption in your idea. Not “will the app be nice”, but the thing that, if false, sinks the whole business. Usually it is “people with this problem will change their behaviour to use my solution”. Everything you test should aim straight at that assumption.
Next, find five to ten real people who have the problem. Not friends, not people who will be kind, actual sufferers of the thing you want to fix. If you cannot find even ten, that is itself a finding worth knowing now. Our guide to validating an idea with five customers covers how to find and talk to them.
Then deliver the value by hand, concierge or Wizard of Oz, and watch what happens. Measure the behaviour that matters: not “did they say they liked it” but “did they come back, did they use it, did they pay”. Talking is cheap; returning is not.
Finally, decide. If the signal is strong, you now have a validated idea and a precise sense of what to build, which makes the build cheaper and faster because there is far less guessing. If the signal is weak, you have just saved yourself a five-figure development bill to learn the same thing. Both outcomes are wins.
Concierge or Wizard of Oz: which to pick
Both methods let you test an MVP with no code, but they answer slightly different questions, so a quick way to choose helps.
| Concierge MVP | Wizard of Oz MVP | |
|---|---|---|
| The user knows | It is done by hand | It looks automated |
| Best for testing | Whether the value is wanted at all | Whether the interface and flow work |
| Effort to run | Lowest, just deliver by hand | A bit more, you fake a product front |
| Strongest signal | Do people engage and pay? | Do people complete the flow themselves? |
| Typical duration | Two to three weeks | Two to four weeks |
As a rule of thumb, start with concierge if you are not yet sure anyone wants the outcome, because it is the cheapest way to find out and it teaches you the work first-hand. Move to Wizard of Oz when you are confident in the value but need to see whether people will actually self-serve through an interface, which is the thing that has to be true before an app is worth building.
Plenty of founders run one then the other. A fortnight of concierge to prove the value, then a fortnight of Wizard of Oz to prove the flow, and you arrive at the build with more certainty than most funded startups ever gather before writing code.
What no code testing will not tell you
Honesty matters here, so let me be clear about the limits. Testing an MVP with no code proves demand and clarifies the product. It does not prove that the thing is technically buildable at a sensible cost, and it does not test how the product behaves at scale. A concierge test with ten users says nothing about what happens with ten thousand.
It also has an expiry date. Doing the work by hand does not scale, which is the whole point, but it means you cannot run a Wizard of Oz test forever. It is a phase, not a business model. The moment the manual version is clearly working, that is your signal to build the real one, because you have earned the right to spend the money.
When to stop testing and start building
The trap on the other side is testing forever because building feels scary. Once you have clear evidence that people want your product, that they will change behaviour to use it, and ideally that they will pay, you have what a no code test can give you. Staying in the fake version past that point is just procrastination with a methodology attached.
At that stage, the job changes from “does anyone want this” to “let us build it well”, and that is a different kind of work. If you want the honest version of what that costs and what the number actually buys, we laid it out in transparent MVP pricing.
What to do next
If you have an idea and have not yet tested it with real people, do not commission anyone to build anything this month. Run a concierge or Wizard of Oz test first. It costs you time and almost no money, and it is the single highest-return fortnight of work available to a founder before launch.
If your no code test has already told you people want this, and you are ready to build the real thing without wasting the momentum, that is exactly the point where a studio earns its keep. Tell us about your project and we will help you turn a validated idea into a product, having already done the hardest part yourself.
.webp)
.webp)
