How to validate an app idea before you spend money on code

You validate an app idea by testing whether people will change what they do, not whether they like it. Start with conversations and a landing page, then test an interactive prototype before you write any code. Stop validating when real people commit something: time, money or data.

The whole job comes down to one question. “How do you minimise risk and how can you validate at breakneck speed?” Most founders skip straight to building because building feels like progress. It’s the most expensive way to find out you were wrong.

“I would rather figure it out in the first two weeks than figure it out in five months’ time.”

What if I build a product no-one cares about?

It’s a fair fear. Ideas fail all the time, and no one’s idea is perfect first time. The real danger is to “overcommit and under-deliver and then find out it’s too late.”

Validation means collecting evidence that a specific group of people has a problem and will act to solve it. Compliments don’t count. “I’d use that” costs nothing to say.

You’re testing three separate things, and it helps to keep them apart:

• The problem. Do enough people feel this pain often enough to care?
• The solution. Does your approach actually fix it, in a way they understand?
• The business. Will someone pay, and can you reach them for less than they’re worth to you?

An idea can pass one test and fail the next. Plenty of real problems have nobody willing to pay for the fix.

How do you validate a startup idea before building?

Get clarity before code. Start cheap, and spend more only as the evidence gets stronger. Here’s the order we’d follow, though the middle steps can flex.

Problem interviews

Talk to 10 to 20 people who have the problem. Ask about the last time it happened, not what they’d want in future. Ask what they tried, what it cost them and what they use now.

If nobody has tried to fix it, that’s often a sign it doesn’t hurt enough. Don’t pitch in these conversations. The moment you describe your app, people start being polite.

Look at what people already pay for

Competitors are good news. They prove people spend money on the problem. Note their prices too, because they set what your customers expect to pay. Your job is to find the group they serve badly.

Spreadsheets, WhatsApp groups and paper forms are competitors too. They’re often the hardest ones to beat, because they’re free and already open.

Landing page and sign-ups

Write one page that states the promise and asks for an email address. A Squarespace site is plenty, and if it does the whole job, you may not need an app yet. Sign-ups tell you the promise lands. They don’t tell you anyone will pay.

Concierge and wizard-of-oz tests

A concierge test means delivering the service by hand to a few customers. A wizard-of-oz test looks automated to the user, but a person does the work behind the scenes. Both show whether the outcome is valuable before you pay to automate it.

Why should you ask for money, not opinions?

Because opinions are free, and everyone near you is biased. Most founders will recognise this. “If you ask your mum if you’ve got the best idea ever, she’s probably like, yeah, that’d be so good.”

Friends want you to succeed. Agencies want the build. That includes us, so treat our enthusiasm with care too. The only test nobody can be polite about is a request to pay.

“Would you give me £10 right now to buy this product and I will deliver it to you in three months? That is [a] much different level of question.”

The strongest early signal is a payment, a deposit or a signed letter of intent. If you’re selling to businesses, one paid pilot is worth more than a hundred sign-ups. If people won’t commit anything yet, find out why before you build.

Pre-selling feels awkward when the product doesn’t exist yet. Be straight about it. Tell people what you’re building, when you expect to deliver and what happens to their money if you don’t. If you sell to consumers, agree a delivery date in writing and offer refunds. Consumer law expects both (Consumer Rights Act 2015, s28).

How we tested LaunchPad itself

We hold ourselves to the same rule. We built the first LaunchPad site and its research in about three days. Then we ran small Google Ads campaigns on niche searches, such as fixed-cost apps, to see who was looking. The risk was tiny next to building a full product first.

MVP vs prototype: what’s the difference?

A prototype shows how the product would work. An MVP, or minimum viable product, is the smallest version that tests whether the business works with real users. It’s often working software, but a concierge service can be an MVP too.

Founders often build an MVP when a prototype would have answered the question. Ask yourself what you’re trying to learn. If the answer is “will people get it?”, you don’t need code yet.

What does an interactive prototype prove?

A design prototype is a set of linked screens you can tap through on a phone. It usually has no real code or data behind it. It looks real enough that people forget it isn’t.

Put it in front of five to eight target users and give each one a task. Watch where they hesitate, misread a button or give up. Don’t help them. Every time you explain something, you’ve found a design problem.

A prototype is good at proving that:

• people understand what the product is for within seconds
• they can complete the core task without help
• the features you thought mattered are the ones they reach for

It can’t prove they’ll come back next week, or that they’ll pay. Those need working software.

This is why every LaunchPad package includes an interactive prototype to test before build. Changing a screen in a design tool takes minutes. Changing it in finished code can take days.

Where validation fits: Ultra Goldfield Logistics

Ultra Goldfield Logistics spotted a gap in last-mile delivery, the final step of getting a parcel to someone’s door. They wanted to match people who need parcels moved with drivers who are already on the road.

Before committing, they phoned round and knocked on doors to see who’d use it and pay. Then they took a clickable prototype back to the same people.

Alongside that came a competitor review, a clear view of which user groups they’d serve and a sharper market position. They also needed a brand, so we designed one.

Only then did we design and build two products. One was a customer portal for requesting deliveries. The other was a driver app that shows the most relevant nearby parcels. The platform was delivered in 3–4 weeks. That was a focused first version, built on validated scope.

We also built data collection in from the start, so routes and driver matching can improve with machine learning later. That’s a validation habit too: build so the product keeps teaching you. Read the Ultra Goldfield Logistics story.

When do you stop validating and start building?

Validation can turn into its own kind of procrastination. Set your stopping rule before you start, so the evidence decides, not your nerves.

You’re ready to build when most of these are true:

• you can describe your user in one sentence, specifically enough to go and find them
• a handful of them have described the problem without being prompted
• you know what they use today, and why it falls short
• some have committed something, like a deposit, a pilot or a pre-order
• target users have completed the core task in your prototype without help
• you can name the hardest, riskiest feature, and you’ll build it first

Stop and rethink if one of these happens instead:

• interviews keep surfacing a different problem from the one you started with
• people like the idea, but nobody commits anything
• you can’t find users to talk to, which means you’ll struggle to find customers too

A pivot after three weeks of interviews is cheap. A pivot after six months of build isn’t.

Mistakes that make validation worthless

• Counting likes and follows. Attention isn’t demand. Only commitments count.
• Testing the wrong people. Ten enthusiastic students tell you nothing about busy finance directors.
• Changing the test halfway. Decide what result means “go” before you look at the numbers.
• Validating features, not the problem. Arguing over buttons before you know the pain is real wastes everyone’s time.

When this isn’t worth doing

Not every idea needs a formal validation phase. Skip most of it in these cases.

• You are the customer. If you’ve run the business for years and the tool fixes your own daily pain, you already have the evidence.
• A customer is paying you to build it. A signed contract is the strongest validation there is.
• It’s an internal tool. If your own team will use it, sit with them for a day instead.
• The cheapest test is the product. Some ideas, like a simple booking site, cost little enough that launching is the test.

Problem interviews are yours to do, because customers tell founders things they won’t tell a supplier. Discovery then tests the solution and the plan with you.

How much does validation cost compared with building?

Most of the tests above cost your time and a modest budget. Building is where the real money goes. Our LaunchPad prices are fixed, excluding VAT:

• Starter: £25k, launched in 2 months.
• Growth: £60k, 3 months.
• Scale: £100k, 4 months.

Each one starts with Discovery, where we test the idea, the users and the plan with you. If the plan isn’t right after Discovery, you get your money back. Growth also includes competitor analysis and a go-to-market strategy.

For a rough figure on your own idea, try the app cost estimator. Our non-technical founder build playbook covers what happens once validation is done.

And if the evidence says no, that’s a result, not a failure. As we tell founders, “There shouldn’t be shame in having an idea, and then figuring out it’s actually not a good idea.”

If you’ve run the cheap tests and the evidence points one way, the next step is a prototype people can hold. See what each LaunchPad package includes on our pricing page, or talk to us about your idea first.