Guide · 7 min read

How to test an idea before building anything

Cheap, honest tests you can run before writing code: what each one actually proves, and how to avoid tests that only produce reassurance.

Every test buys you information at a price. The skill is choosing the test that buys the most information about your weakest assumption for the least time. Most founders run the reverse: expensive tests on assumptions they were already confident about.

Test the load-bearing assumption first

Start by naming the belief that, if wrong, ends the idea. Usually it is one of three: nobody is actively looking, nobody will pay this much, or you cannot reach them affordably. Everything else is a detail that can be fixed later.

Five tests, in order of cost

1. The substitute audit

Find five people in the segment and document exactly what they do today. Cost: a few hours. Proves: whether the problem is currently being solved badly, or simply not felt.

2. The artefact test

Produce the output of your product by hand (the report, the summary, the plan) and give it to someone. Cost: one afternoon per person. Proves: whether the output itself is wanted, independent of any software. If nobody asks for it again, the product will not save it.

3. The channel test

Pick one channel and spend a fixed ten hours on it with no product built. Cost: ten hours. Proves: whether you can reach the buyer at all. This is the test most often skipped and most often decisive.

4. The price conversation

State a real number to a real prospect and stop talking. Cost: minutes. Proves: whether budget exists. Watch for hesitation, not for agreement.

5. The pre-sale

Ask for money or a signed commitment before the product exists. Cost: your comfort. Proves: more than the other four combined.

Tests that mostly produce comfort

Asking whether people 'would use' something, because hypothetical behaviour is not behaviour.
A landing page with no traffic source, which tests your copy against nobody.
Market-size research, which tells you the room is big, not that anyone in it wants this.
Asking an AI model to critique the idea and treating its answer as data.

A structured evaluation is genuinely useful for deciding what to test: it turns a vague idea into a ranked list of assumptions. It cannot replace the test itself, and any tool claiming otherwise is selling comfort.

Set the failure condition before you start

Decide in advance what result would make you stop. Written down, before the test. Without it, every ambiguous outcome gets read as encouragement, and the test becomes theatre.