How to Validate a Startup Idea (2026)

The most expensive way to test a startup idea is to build it. Yet that is exactly what most founders do first — three months and £20K later, they finally learn what a week of conversations would have told them for free. Validation is the step that comes before you decide what to build, and it is the cheapest insurance money can buy. Here is how to do it properly, without writing a line of code.

How do you validate a startup idea before building it?

You validate a startup idea by identifying its riskiest assumption, then testing that assumption directly with real potential customers — through interviews, willingness-to-pay signals, and cheap demand tests like landing pages — until you have evidence people will actually pay, all before you write any code. Validation is a research exercise, not a build exercise. The goal is to be proven wrong quickly and cheaply, so you only spend real money on ideas that have already survived contact with the market.

Most founders skip this because building feels like progress and asking feels like doubt. But every hour spent validating saves weeks of building the wrong thing. Below is the framework we walk UK founders through before they commit a build budget.

Step 1: Define your single riskiest assumption

Every idea rests on a stack of assumptions. Some are safe ("people use email"). One or two are load-bearing — if they're wrong, the whole business collapses. That is what you validate first.

Write your idea as a sentence, then underline the part most likely to be false:

"Freelance bookkeepers will pay £40/month for a tool that auto-chases late invoices because chasing manually wastes hours every week."

Each italicised phrase is an assumption. Usually the riskiest one is either "they have this problem badly enough to pay" or "they'll pay this much." Rarely is it "can we build it" — for most SaaS the technology is proven, and the market is the real unknown. (If your risk genuinely is technical feasibility, that's a different artefact — see MVP vs prototype vs POC.)

Pick one assumption. Validate that one thing before anything else.

Step 2: Talk to real potential users

The single highest-leverage validation activity is talking to people who have the problem — not friends, not your co-founder, not Twitter. Real prospects in your target segment.

The trick is to interview the problem, not the idea. Founders who pitch their solution get polite encouragement. Founders who ask about the current reality get the truth. Use a script like:

"I'm researching how people handle [situation]. I'm not selling anything — can I ask how you deal with [specific task] today?"

Listen for two signals:

1. Do they describe the pain unprompted? If you have to explain why it's a problem, it isn't one they feel.
2. Are they already paying to solve it — with spreadsheets, freelancers, a competing tool, or their own time? Existing spend is the strongest proof a problem is real.

Avoid the classic trap of asking "would you use this?" People are generous with hypotheticals and stingy with money. Ask what they did last time they hit the problem, not what they would do.

Step 3: Test willingness to pay — not just interest

Interest is cheap. "That sounds useful" costs nothing to say and predicts nothing. Willingness to pay is the only signal that separates a business from a hobby, and you can test it long before a product exists.

Concrete ways to test payment intent pre-build:

• Ask for a pre-order or deposit. "I'm building this — £50 gets you the first three months at half price." A card entered is worth a hundred compliments.
• Sell the service manually first (a concierge test — see Step 4) and charge real money for it.
• Name a price in interviews and watch the reaction. Flinching, negotiating, or "that's reasonable" all tell you more than a thumbs-up.

Money changing hands — or a genuine commitment to it — is the validation that actually de-risks a build. Everything softer is a proxy.

Step 4: Run a cheap demand test

Once interviews suggest a real problem, test demand at slightly larger scale without building the product. Three proven, low-cost methods:

• Landing page test. A one-page site describing the product with a clear price and an email capture or "Get early access" button. Drive a small amount of traffic (a few hundred pounds of ads, or posts in the communities your users live in) and measure sign-up rate. This tests whether the value proposition lands with strangers, not just interview subjects.
• Fake-door test. Add a "Buy" or "Start free trial" button that leads to a "We're launching soon — join the waitlist" page. Clicks measure genuine intent to act, not just curiosity.
• Concierge test. Deliver the outcome manually, by hand, for your first few customers — no software at all. If bookkeepers will pay you to chase invoices while you do it in a spreadsheet behind the scenes, you've proven demand and learned the workflow you'll eventually automate.

These cost a few hundred pounds and a week or two. Compare that to the £15K+ a production MVP costs and the value of validating first is obvious.

Step 5: Make an honest go / no-go decision

Set your success criteria before you run the tests, so you can't move the goalposts afterwards. Something like:

• 15+ interviews completed, and a clear majority describe the problem unprompted
• At least 5 people gave a real payment signal (deposit, pre-order, or firm price agreement with a name attached)
• Landing page converts visitors to sign-ups at a rate you'd defend to an investor

If you hit your criteria, you've earned the right to build — go scope the smallest thing that delivers the core value (see how to scope a SaaS MVP in 8 weeks). If you didn't, you haven't failed — you've saved yourself a five-figure mistake. Iterate on the segment, the problem, or the price, and test again. The founders whose products die are usually the ones who skipped this step and built on a guess.

How do you validate without writing code?

You validate without writing code by using interviews, landing pages, fake-door tests, concierge delivery, and pre-sales — methods that test demand and willingness to pay using words, mock-ups, and manual effort instead of software. None of these require an engineer.

The mindset shift is treating your product as a service you deliver manually before it's a product you build. If you can't get anyone to pay you to solve the problem by hand, no amount of code will change that. And if they will, you've validated the idea and learned exactly what to automate first. No-code tools (a form, a simple landing page, a payment link) are more than enough to run every test above. Writing code is the reward for passing validation, not the way to do it.

How many customer interviews do you need?

Aim for 15 to 20 interviews with real prospects in one specific segment — enough to hear patterns repeat, but not so many that you're stalling instead of deciding. The number matters less than the quality: twenty conversations with your actual target buyer beat a hundred with a vague "anyone interested."

You'll know you have enough when interviews stop surprising you — when the fourth person describes the same pain in the same words as the first three. That repetition is the signal you understand the problem well enough to act. If every interview tells a wildly different story, your segment is too broad; narrow it and keep going.

When are you validated enough to build?

You're validated enough to build when you have clear evidence of a painful problem and a real willingness to pay — typically several prospects who have committed money or a firm intent to it, not just verbal enthusiasm. Validation is never 100%; you're looking for enough evidence to justify the risk, not certainty.

Once you're there, the type of build depends on your remaining risk. If demand is proven but you're unsure the experience will click, a £5K validation prototype tests the flow before you commit to engineering. If you're confident in both problem and solution and just need real, paying usage, a £15K MVP is the right next step. The difference between the two is covered in MVP vs prototype vs POC, and both are laid out on our pricing page. What you should not do is jump straight to a full build on the strength of a good idea and a few nice comments.

Frequently asked questions

Can you validate an idea without a product?

Yes — in fact you should. Interviews, landing pages, fake-door tests, and pre-sales all test real demand before a product exists. The product is what you build after validation succeeds, not the tool you use to run it. Building first is the most expensive possible way to learn your idea was wrong.

How much should validation cost?

Usually a few hundred pounds and one to three weeks of your time. Interviews are free; a landing page and a small ad budget rarely exceed £300–£500. Compare that to a £15K MVP and validation is the cheapest insurance you'll ever buy. If your remaining risk is the experience, a £5K validation prototype is the next tier up — but only after the free tests pass.

What if people say they like it but won't pay?

Then it isn't validated — and you've just learned something valuable for free. "I like it" is interest; a card entered is validation. When people praise an idea but won't commit money, either the problem isn't painful enough, your price is wrong, or you're talking to the wrong segment. Adjust one variable and test again before you build anything.

Is validation the same as market research?

No — market research describes a market; validation tests whether your specific idea will sell in it. Research tells you the bookkeeping software market is worth billions; validation tells you whether fifteen real bookkeepers will pay you £40/month for your specific tool. Only the second one de-risks a build.

The bottom line

Validation is the pre-build step almost everyone skips and almost no one regrets doing. Name your riskiest assumption, talk to real prospects about the problem, test whether they'll actually pay, run a cheap demand test, and make an honest go/no-go call — all before an engineer touches the project. Do it well and you either kill a bad idea for a few hundred pounds, or walk into your build with evidence instead of hope.

Want to test demand without betting a full build budget on a guess? Book a free 30-minute scoping call — we'll help you name your riskiest assumption and, if a build is warranted, scope a validation prototype that tests real demand cheaply before you commit to a full MVP.