How to validate an app idea by building it
The fastest way to validate an app idea is now to build a working version of it and put it in front of someone, because building one has become cheap enough that it is no longer the expensive step. For most of the last decade that advice would have been irresponsible — a prototype cost weeks — so the standard method was to test a description of the idea instead.
That constraint has moved. The methods built around it are worth revisiting.
What a mockup actually tests
A landing page, a survey or a clickable prototype tests whether your description appeals to someone. That is a real signal and it is not nothing. It is also not the question you are usually asking.
People are reliably enthusiastic about ideas and unreliable about their own future behaviour. "Would you use this?" measures politeness as much as intent. The thing you actually want to know is whether someone picks the app up a second time, and only a working app can answer that.
What changes when building is cheap
The classic argument against building first was sunk cost: three weeks in, you are attached to the thing and you will interpret weak signals generously. That effect is real, and it scales with the effort spent.
An afternoon does not generate the same attachment as a month. When a version costs an afternoon, you can build the idea, watch it fail, and start the next one without any of the psychology that makes founders defend a bad idea. Cheap building does not just speed up validation — it makes you more willing to accept a bad result.
It also changes what you can test. Two versions of an idea with genuinely different mechanics is a comparison almost nobody could afford to run before, and it is a much better question than asking one group of people what they think.
What a working prototype still does not tell you
Being straight about this matters more than the rest of the post, because the failure mode of cheap building is building a great deal of the wrong thing very efficiently.
- Whether anyone will pay. Usage and willingness to pay are different measurements, and the gap between them has killed a lot of well-used products.
- Whether you can reach these people repeatedly. A prototype tested on ten friends says nothing about acquisition, and acquisition is where most ideas actually die.
- Whether the market is big enough. Ten delighted users is the same signal whether the total market is ten thousand or two hundred.
- Whether it holds up at scale. Something that works for one person may be a completely different engineering problem for a thousand.
Building cheaply removes one obstacle. It does not convert a product question into a technical one.
A sequence that works
- Write down what would have to be true for the idea to work, and which of those you are least sure about. That is what you are testing; everything else is decoration.
- Build the smallest thing that exercises exactly that assumption. Not a product — the one flow that would prove or kill it.
- Put it in front of five people who have the problem, and say as little as possible while they use it. What you are watching for is whether they get stuck, not whether they are complimentary.
- Decide before you watch what result would make you stop. Deciding afterwards is how a weak signal becomes a strong one.
The fourth point is the one people skip and the one that does the work. Without it, cheap building produces a stream of prototypes that all somehow deserve another week.
What to watch while they use it
The session itself is where most of the value is, and most people waste it by talking. Three things are worth more than anything a participant tells you afterwards.
- Where they hesitate. A pause before a click is a design problem you cannot see in your own product, because you already know what the button does.
- What they try that does not exist. Someone reaching for a feature you did not build has just told you what the product is missing, without being asked.
- Whether they come back. Set the thing up so you can tell, then wait a week and say nothing. Unprompted return is the only enthusiasm that has ever meant anything.
What this costs to do
Less than it used to, which is the whole premise. With Adrian the local path costs nothing at all — you describe the app, it builds a working version with a live preview, and there is no account, no key and no per-build charge. If your machine can hold a reasonable model, testing five ideas costs five afternoons and no money.
If you would rather use a frontier model, bringing your own API key means you pay your provider directly at their rates, and what that actually costs breaks down what drives the number. Either way the code is yours, on your disk, which matters more than it sounds when the fourth idea is the one that works and you want to keep going.
The honest part
A generated prototype is a prototype. It is good enough to put in front of someone and watch them use it, which is exactly what validation requires, and it is not a product you should charge for on day one. Expect to rebuild the parts that survive.
That is a feature rather than a problem. The point of validating this way is to find out which parts deserve to be built properly, and the ones that do are a much shorter list than the ones you would have built by guessing.