Why most "good ideas" fail - and how to test yours early

A friend of mine - smart, driven, the kind of person who reads three books a month and still finds time to train for a half marathon - spent the best part of a year building an app for dog walkers. She'd talked to friends, family, a few people at a coworking space. Everyone said the same thing: "That's a great idea, I'd totally use that." So she hired a developer, burned through about £40k of savings, launched it, and… nothing. Not a dramatic crash. Just silence. Twelve downloads in the first month, most of them from people she already knew.

The idea wasn't bad. But she'd built a product around a problem she'd assumed existed, for an audience she'd never properly spoken to, with features nobody had asked for. She'd mistaken encouragement for evidence.

And honestly? That's one of the most common stories in startups. Not reckless spending or terrible execution - just a founder who moved too fast past the one step that mattered most.

The idea isn't the risk - untested assumptions are

Here's the thing nobody tells you early enough: your idea is probably fine. Most startup ideas have a kernel of something real in them - a genuine frustration, an obvious gap, a moment where you thought "why doesn't this exist?" That instinct is worth trusting. What's not worth trusting is the leap from "this should exist" to "people will pay for it."

Because between those two statements sits a stack of assumptions you've probably never written down, let alone tested. Assumptions about who your customer is, what they're actually struggling with, how much they'd pay, whether they'd switch from what they're already using, and whether the problem bothers them enough to do anything about it at all.

That stack of assumptions? That's where the risk lives. Not in the idea itself.

Put another way: a good idea and a proven idea are two very different things. And the gap between them is entirely closable - often in a matter of days, not months - before you write a single line of code or spend a penny on development.

"But people told me they love it"

Of course they did. Your mum loves it. Your mate from uni thinks it's brilliant. Even that bloke at the networking event who nodded enthusiastically and said "you should definitely build that" - he meant well. But none of those people were reaching for their wallet.

There's a well-documented problem in early-stage validation called courtesy bias. People are wired to be supportive, especially when you're visibly excited about something. They'll tell you what you want to hear, not what you need to hear. Rob Fitzpatrick's book The Mom Test is practically required reading on this - his core argument is that you should never tell anyone your idea. Instead, ask them about their life, their problems, their behaviour. If the problem is real, it'll surface without you prompting it.

So when someone says "yeah, I'd use that", what they're really saying is "I don't want to make this awkward." And that's a very different data point.

What testing actually looks like (and why it's cheaper than you think)

When we say "test your idea," we're not talking about a six-month research project or a £20k prototype. We're talking about something much simpler and faster - a structured way of poking holes in your assumptions before they become expensive mistakes.

Here's what that tends to look like in practice:

1. Talk to real potential customers - not friends. Five to ten honest conversations with people who actually have the problem you're solving will teach you more than a year of desk research. Ask about their current workarounds, what frustrates them, and what they've already tried. If they haven't tried anything, that tells you something too.
2. Map your riskiest assumptions. Write down every assumption your idea depends on - then rank them by how catastrophic it would be if they turned out to be wrong. Start testing from the top. You don't need to validate everything, just the stuff that would sink you.
3. Build the smallest possible thing that proves demand. This might be a landing page with a sign-up form. A spreadsheet you run manually behind the scenes. A concierge version where you deliver the service by hand before automating anything. The goal isn't a product - it's proof that someone wants what you're offering enough to take action.

The cost of doing this properly? A few weeks and very little money. The cost of skipping it? Ask my friend with the dog-walking app.

You're not killing the dream - you're protecting it

Let me be clear about something: none of this is about talking you out of your idea. It's about making sure your idea gets the best possible shot at working. Founders who validate early don't build less - they build smarter. They arrive at the development phase with clarity about what to build, who it's for, and why it matters. And that means less wasted time, less wasted money, and a much better chance of building something people actually want.

The founders who struggle most aren't the ones with bad ideas. They're the ones who treated a hunch like a certainty and went all-in before checking whether the ground beneath them was solid.

So before you brief a developer, before you name the company, before you start thinking about logos - ask yourself: what would have to be true for this to work? And then go find out if it is.

Ready to stress-test your idea? Book a free idea conversation with the Rise team - 30 minutes with a founder who's done this a few hundred times, no obligation, and you'll come away with something useful whether we end up working together or not. No pitch, no pressure - just an honest look at where you stand.