With no audience and no budget, the first question is not which test to run. It is how many people have to see the thing before the answer means anything — and the number is larger than it feels. Even in the friendliest corner of the grid below, one paying customer takes 20 qualified arrivals. Most founders conclude "nobody wants it" somewhere around ten, which is not a finding. It is a sample size.
Silence is the expected result, not the verdict
A test with no audience behind it produces silence by default. That is the base case, and it says nothing about the idea, because the experiment never ran.
Here is the whole arithmetic, and it is division. Pick how many paying customers would make you believe, pick a rate at which arrivals turn into money, and the required reach falls out:
Visit-to-paid rate | 1 paying | 5 paying | 10 paying |
|---|---|---|---|
| 1% | 100 | 500 | 1000 |
| 2% | 50 | 250 | 500 |
| 5% | 20 | 100 | 200 |
Qualified arrivals required, computed as payers divided by rate. The rates are probes rather than measurements of anything — what the grid establishes is the order of magnitude, not a forecast for your product. The corner that matters is the cheapest one: 20 arrivals for 1 paying customer, at a rate most products never reach.
Spread over a month of evenings, the friendliest corner — one paying customer at the best rate — is 5 qualified arrivals a week. The harshest, 10 payers at the worst rate, is 250 a week. Both are jobs. Neither is "post it and see".
The practical consequence is a change of plan rather than of effort. If you cannot plausibly reach the number in the cell you picked, do not run that test — pick a test whose signal arrives earlier: replies instead of payments, a written commitment instead of a purchase, a price on the page instead of a waiting list. A cheaper signal is not a weaker one when the expensive signal is unreachable.
The four channels available when you cannot buy any
| Channel | What it costs | First arrival | The catch |
|---|---|---|---|
| Answering the question where it was asked | Your time, one thread at a time | Same day | Does not compound, and most communities remove a pitch |
| Being listed where people go to look | An afternoon of submissions | Days to weeks | One burst per listing, and the burst is mostly other founders |
| Writing the page the buyer searches for | Weeks before anything arrives | Months | Compounds, but too slow to settle the question in front of you |
| Messaging people who already wrote about the problem | Your time, and a real risk of being a nuisance | Same day | Does not scale, and the reply rate is the experiment |
A classification, published so a row can be argued with. Read the last two columns together: the channels that arrive today do not compound, and the one that compounds does not arrive in time to settle the question you have now.
The fourth row is the one people avoid and it is usually the right first move. Someone who wrote publicly about the problem last month has already done the hardest part — they identified themselves. Our own pipeline is built on the same observation: it reads public complaints and publishes the ones it finds, with links, because a documented problem has an author and an author has an inbox.
One message per person, referencing the specific thing they wrote, asking a question rather than pitching. The reply rate is itself the experiment, and unlike a page view it comes with a sentence attached.
Your own numbers will understate the reach
This is where small experiments quietly go wrong, and it is a measurement problem rather than a marketing one. Here is the rule we hold ourselves to about which source may answer which question:
| The question | What may answer it | What may not |
|---|---|---|
| Impressions, position, queries | Google Search Console / Bing Webmaster Tools | PostHog pageviews — consent-gated, so they are a floor on arrivals, never a total. |
| Behaviour on the site | PostHog, consented only | Anything describing all visitors. The consent-grant rate must be reported beside it. |
| Runs, activation, entitlement | The database | PostHog events, which can drop and are consent-gated on the client seam. |
| Payment | The provider plus the credit ledger | PostHog revenue, which is a projection and never the financial source of truth. |
| Which page produced a signup | SignupAttribution, consented rows only | A rate. Attributed signups are a floor: the population that consented differs from the population that signed up by an unmeasured amount. |
The 5 rules we apply to our own measurement, imported from the module that defines them. The third column is the useful one, and the first row is the one that breaks a small test: consent-gated analytics report a floor on arrivals, never a total.
The damage is specific. Your conversion rate has arrivals underneath and payments on top, and the two come from populations that differ by an amount nobody can measure — so the rate is wrong in the direction that makes your test look worse than it was. At a hundred arrivals that error is invisible and decisive.
Two defences, both cheap. Count arrivals at the server where you can — a redirect, a distinct landing path per channel — and treat the client-side number as a lower bound. And write the bar as an absolute count rather than a percentage: "five people paid" survives a broken denominator, and "two per cent converted" does not.
What this cannot fix
It cannot manufacture an audience, and it does not claim the free channels add up to a paid one. They do not. What they can do is get you to the smallest cell in that grid, which is enough to distinguish "nobody wants this" from "nobody has seen it" — and that distinction is the entire question at this stage.
It also cannot tell you your real conversion rate, because you do not have one yet. Everything above is a planning grid; the moment you have your own numbers, use those and throw the probes away.
The short version
- Work out the arrivals your test needs before running it. One paying customer takes 20 qualified arrivals at the best rate in the grid and 100 at the worst; 10 of them takes 1000.
- If you cannot reach that number, change the signal rather than the effort: replies, commitments and prices arrive earlier than purchases.
- With no budget, the channels that arrive today do not compound and the one that compounds arrives too late. Use both, for different purposes.
- Count arrivals server-side and write your bar as a count, not a percentage. A consent-gated denominator makes a small test look like a failure.