"Build something you need yourself." It's the most common advice in the indie hacker playbook. It sounds right. It feels right. And it's leading people astray.
The advice isn't always wrong. But it's incomplete in ways that cause real damage. Here's what nobody tells you about scratching your own itch.
The Seductive Logic
The argument goes like this:
This logic is why Basecamp was built (37signals needed project management), why Stripe exists (developers hated payment integration), why countless successful products started as internal tools.
So what's the problem?
The Problems Nobody Mentions
Problem 1: You Are Not the Market
Just because you have a problem doesn't mean other people have it. Or that enough people have it. Or that they have it badly enough to pay.
You are a sample size of one. Your preferences, workflows, and pain tolerance are specific to you. Founders have built tools they desperately wanted that nobody else cared about. The pain was real; the market wasn't.
The developers who built Stripe weren't just scratching their own itch. They validated that millions of other developers had the same itch. That validation step is the part people skip.
Problem 2: Power Users Make Terrible Targets
If you're deep enough into a problem to build a solution, you're probably a power user. You've developed workarounds. You've learned to tolerate friction that drives normal users crazy.
A sophisticated tool with 47 features, keyboard shortcuts for everything, and assumptions baked in that only make sense if you've used the category for years.
Something simple that solves one problem for people who don't want to become experts in yet another tool.
Your itch leads you to build for yourself. But you're the worst possible customer archetype: demanding, edge-case-prone, and representative of nobody.
Problem 3: Passion Doesn't Equal Business
You might genuinely care about solving a problem. But caring doesn't mean people will pay. Some of the most passionate niches have the worst unit economics.
The passion trap: Indie hackers, developers, and creators are notoriously hard to monetise. If your itch comes from being part of these communities, you're scratching in a tough market.
Meanwhile, boring industries like insurance software, logistics tools, and B2B compliance have enormous demand and customers who expect to pay thousands per year. Nobody scratches those itches because nobody has those itches organically.
Problem 4: You Solve for Today, Not Tomorrow
Your current problem exists in your current context. But contexts change:
- You change jobs and the problem disappears
- A platform update makes your solution obsolete
- You outgrow the problem as your own skills develop
Founders have built tools that perfectly solved their problem at the time. Then their situation changed and they stopped caring. If their situation changed, others' did too. The market evaporated while they were still building.
What Actually Works
The fix isn't to ignore your own problems. It's to add rigour to the process.
Step 1: Scratch, Then Validate
Your itch is a hypothesis, not a business plan. Treat it that way.
- Can you find 10 other people complaining about this problem online?
- Are there existing solutions? What do their reviews say?
- Would people pay? What's the evidence?
If you can't answer these, your itch might be personal, not profitable.
Step 2: Build for Beginners, Not Yourself
Resist the urge to add every feature you want. Build the simplest thing that solves the core problem for someone who isn't you.
Your MVP should make you slightly uncomfortable. If you'd actually use it yourself, you've probably overbuilt.
Step 3: Follow the Money, Not Just the Pain
Some itches aren't worth scratching commercially. Check:
A painful problem with no monetisation path is a hobby project, not a business.
Step 4: Consider Scratching Someone Else's Itch
Here's the real heresy: you don't need to have the problem yourself.
Many successful indie hackers build for markets they're not in:
- Developers building for restaurants
- Designers building for accountants
- Former employees building for their old industry
What you need isn't personal pain. It's access to people with pain, willingness to listen, and ability to execute. You can learn about someone else's itch faster than most people can learn to code.
When "Scratch Your Own Itch" Actually Works
The advice isn't always wrong. It works when:
Your problem is shared by a large, reachable, paying market. You're typical, not unique.
You don't just assume. You talk to others, find evidence, and confirm the market exists.
Despite having the problem, you build for the average user, not yourself.
The target market pays for software, is reachable, and supports your pricing.
The Better Advice
"Scratch your own itch" should be: "Start with problems you understand, then validate aggressively."
Your personal experience is an advantage, but only if you don't let it blind you. The itch gets you interested. Validation tells you whether anyone else cares.
The next time someone tells you to scratch your own itch, nod politely. Then go find evidence that the itch is shared, serious, and solvable as a business.
That's the part they always leave out.