How to test a startup idea for under £1,000.

Here is a pattern I have watched too many times. A founder has an idea they believe in, so they do the obvious thing: they find someone to build it. Three months and a five-figure invoice later, they have a product, they launch it, and the market is quiet. The idea might have been fine. The problem is they spent the money to find out, when they could have found out first for a fraction of it.

Building is how you deliver an idea people already want. It is a slow, expensive way to discover whether they want it. Before you build, there is a cheaper job to do, and it has a name: validation. The whole point is to spend as little as possible to learn as much as possible, and for an early-stage founder, where money is runway and runway is survival, that is one of the highest-value things you can do. This is the practical companion to an earlier issue on not spending: here is what to do instead.

First, name the riskiest assumption.

Every idea rests on a stack of assumptions, but they are not equally risky. Before you pick a test, ask which single belief, if it turned out to be wrong, would sink the whole thing. It is usually one of three:

• Do they even care? The problem might not be painful enough for anyone to act.
• Will they pay? They might care, but not enough to open a wallet.
• Does this solution work? They might want it, but your particular version might miss.

The cheapest useful test is the one that attacks the riskiest of those, first. Here are the five to reach for.

1. The smoke test (does anyone care?)

Build a single landing page that describes the product as if it exists, with one clear action: sign up, join the waitlist, or "buy now." Point a small amount of paid traffic at it and watch what people do. A no-code page is free; a modest ad budget to get real strangers in front of it is the only cost. What it proves: whether the promise is compelling enough that people will raise a hand. Rough cost: £100 to £300. The trap is counting sign-ups from friends. You want cold strangers, because they are the market.

2. The fake door (which feature is wanted?)

If you already have something live, add the entrance to a new feature (a button, a menu item) that leads to a "coming soon, join the list" screen instead of the real thing. Count the clicks. What it proves: genuine demand for a specific feature among people already using your product, before you build it. Rough cost: near zero. A word of care: be honest and quick to follow up, or you spend trust you can't easily earn back.

3. The concierge test (is the outcome valuable?)

Deliver the outcome your product promises, but do it by hand, for a handful of real customers, with no product built at all. If you are planning an app that automates something, do that something manually over email and a spreadsheet first. What it proves: whether people value the result enough to keep coming back, and, just as usefully, what actually goes into delivering it. Rough cost: your time. It is unglamorous and it does not scale, which is exactly why it teaches you so much before you automate the wrong parts.

4. Pre-sales (will they actually pay?)

Ask people to pay, or firmly pre-commit, before the thing exists. A pre-order, a paid pilot, a founding-member price, a crowdfunder. What it proves: the strongest signal there is, because it is the only test where the answer costs the customer something. Rough cost: near zero to set up. Interest is cheap and people are polite. A card payment is neither. If you can pre-sell it, you have something; if you cannot, better to know now.

5. The ten-user prototype (does the solution land?)

Once demand looks real, a clickable prototype (in a design tool or a no-code builder) put in front of about ten target users tells you whether your particular solution actually works: whether they understand it, whether it fits the job, where it confuses. What it proves: the shape of the solution, before engineering makes it expensive to change. Rough cost: £200 to £500 including small thank-yous for testers. This is the exact ground the Prototype Set Piece covers when you want it done properly and fast.

Sequence them, don't do all at once.

You do not run five tests in parallel. You run the one that attacks your biggest unknown, and you let the result decide the next move. If the smoke test gets no clicks, you have your answer and you have spent two hundred pounds, not twenty thousand. If it converts, the fake door or a concierge round tells you whether the interest is real. Only once demand looks solid does a prototype earn its place, because a beautiful prototype of something nobody wants is just an expensive way to feel busy.

The one rule underneath all of it.

Spend the least to learn the most. Every one of these tests is a way of buying a piece of certainty cheaply, before the expensive commitment. The founders who last are not the ones who move fast to build. They are the ones who move fast to learn, and who treat every pound spent before validation as a pound they might never see again. When building was expensive, this discipline was optional for the well-funded. Now that building is cheap and getting cheaper, the scarce skill is not making things. It is knowing which things are worth making, and finding out for next to nothing.

How we use this at Product Pieces.

Most founders who come to us are one conversation away from spending real money on a build. The free Diagnostic is twenty minutes to work out whether the piece your product function is missing is the discipline to test before you spend, and which of these experiments fits your riskiest assumption. When the answer is a prototype, the Prototype Piece gets it in front of real users fast. And if you are holding a build quote already, the Sanity Check is the read on whether that money is about to be well spent. Often the most valuable thing we do is help you not spend it yet.