Why I stopped trusting "good ideas"

The startup world has a particular mythology around ideas. The founding story where someone had a flash of insight in the shower. The "eureka moment" that preceded everything. The idea that came at the right time, to the right person, and changed everything.

This mythology is mostly harmless when it's someone else's story. It becomes a problem when it shapes how you approach building your own.

For a long time — longer than I'd like to admit — I operated from a framework that went roughly like this: a strong idea, well executed, is the foundation. Find the right idea first, then figure out the rest. The problem is that this framework is unfalsifiable in real time. Every idea feels strong before you test it. And testing it properly requires a level of honesty about what you might find that most people, myself included, resist.

The comfortable lie is that you can tell a good idea from a bad one before building it. You can't. Not reliably. The feeling that you have a good idea is not evidence that you do.

I've built things that didn't work. I'm not going to list them as trophies — they weren't. They were expensive lessons in problem-first thinking that I only understood properly in retrospect.

The pattern was consistent: start with an idea that felt compelling, build towards it with conviction, ignore or rationalise early signals that the problem wasn't as painful as assumed, arrive at a product with genuine technical merit and marginal real-world demand.

The frustrating part wasn't the failure. Failure is part of building anything. The frustrating part was realising, each time, that the signal was there early. Users were polite but not urgent. The workarounds they had weren't that bad. The problem I was solving existed, but it wasn't painful enough to change behaviour.

I was solving inconveniences, not problems.

There's a useful distinction here. An inconvenience is something people would prefer not to deal with but have accommodated. A problem is something they actively spend money, time, or energy trying to fix and haven't found a good solution for.

This is the most dangerous phrase in early-stage building.

It sounds responsible. It sounds like the founder is aware of the need to validate. But it's almost always a rationalisation for avoiding an uncomfortable conversation.

"We'll validate later" usually means: "I know we should talk to users before building, but I'm not ready to hear what they might say. So I'll build first, and then talk to them once I have something to show them." The problem is that by the time you have something to show, you've made dozens of decisions based on unvalidated assumptions.

Paul Graham wrote that "the initial idea is just a starting point." That's true. But a starting point that hasn't been pressure-tested before significant resources are committed is a liability, not an asset.

The difference between a sales conversation and a discovery conversation is the direction of information flow. In a sales conversation, you're transmitting — sharing the idea, gauging enthusiasm, looking for confirmation. In a discovery conversation, you're receiving — asking about behaviour, constraints, current solutions, and the real texture of the problem.

Most founders only know how to have sales conversations.

Painstack.ai came directly from this frustration.

The idea is simple: before you build anything, map the complaint landscape. Find real, documented pain — in forums, reviews, support threads, social media, anywhere people go to express frustration publicly. Understand who is complaining, what they're complaining about, and what they're currently using that isn't working.

This is not a revolutionary methodology. It's closer to market research that should have been done before building, systematised and made accessible.

The insight behind it is that real startup opportunities don't usually hide. They're visible in the places where people complain because they've given up expecting a good solution. They're in the one-star reviews that say "I have no other choice." They're in the Reddit threads where someone asks "does anyone have a better solution for X" and gets twelve responses saying "I've tried everything, I just use a spreadsheet now."

That's the signal. Someone who says "I just use a spreadsheet now" has a problem worth solving.

The shift wasn't dramatic. It was quieter than that.

I stopped starting with ideas and started starting with friction. When I encounter a domain now, whether it's property management, agriculture, fitness, or anything else, I look for the places where people are spending effort they resent, money they can't account for, or time on manual processes they've stopped questioning.

I look for the workarounds. Every domain has them. Spreadsheets that have been running for five years because no software fits the workflow. WhatsApp groups that function as operational systems. Expensive human intermediaries doing work that should be automated. These are the shapes of problems that haven't been solved properly.

I also changed how I have early conversations. I'm less interested in whether someone would use my product. I'm more interested in what their current day looks like, where the stress concentrates, and what they've already tried.

This is what Steve Blank called "customer development": be more curious about the problem than you are attached to the solution.

Today, I don't ask "is this a good idea?" I ask "where is the pain, and who is already paying for relief?"

Not metaphorically paying. Actually paying — in money, in time, in stress, in manual workarounds, in accepting that something is broken because nothing better exists.

That's the starting point. Not the idea.

Ideas are easy. They're abundant. They feel important and they cost nothing. Problems — real ones, with real costs, attached to real people who are actively trying to manage them — are rarer, and they're the only foundation worth building on.

The good news is they're not hard to find. They're everywhere, hiding in plain sight, in the complaints people stopped making because nobody was listening.

Start there.