Why "Scratch Your Own Itch" Is Overrated (And When It Works)

Your itch is not evidence. It's a hypothesis with a sample size of one. Building something because it would solve your own problem tells you the problem exists for at least one person — you — and nothing about whether it exists, at scale, for people who aren't you. Validation still has to happen after the itch, not instead of it.

Quick Answer: Scratching your own itch is a legitimate way to find a problem worth exploring, but it is not a substitute for confirming that problem is common, painful, and shared by people who will pay to have it solved. It works when you're a reachable member of a real market. It fails when you're an outlier — unusual skills, unusual tools, unusual tolerance for pain — mistaking your own workaround for a business.

The Strongest Objection: Famous Companies Started as Founder Problems

The case against this article writes itself, and it deserves a fair hearing before it gets rebutted.

37signals built Basecamp because they needed better project management software to run their own web design studio, and shipped it as a product almost as an afterthought. Buffer started because its founder wanted a simpler way to schedule his own tweets. Ruby on Rails was extracted from Basecamp's codebase to scratch DHH's own itch about writing web applications faster. None of these founders ran a market survey first. They built the thing they wished existed, used it themselves, and only later noticed other people wanted it too.

That pattern is real, and it is not a coincidence. Building for yourself compresses the feedback loop to zero. You don't need to schedule a user interview to find out if a feature works — you know immediately, because you're the one using it. You don't need a persona document to understand the user's context — you already live in it. For a solo founder or a small team without a research budget, that speed advantage is enormous.

But notice what these stories have in common besides the itch: the founders were already deep insiders in the market they ended up serving. DHH wasn't a hobbyist dabbling in web frameworks — he was building production web applications for paying clients every day. The itch didn't come from nowhere; it came from thousands of hours of exposure to a problem shared by everyone doing similar work. The itch was the symptom. The insider position was the actual asset.

That distinction is the whole article. Survivorship bias makes "I built it for myself and it worked" sound like a strategy, when the visible cases are the ones where the founder's personal situation happened to be representative of a real market. Nobody writes a case study about the founder who spent a year building an elaborate tool for a workflow so specific to their own life that literally no one else has it — but that founder exists in far greater numbers than the Basecamp story suggests, silently and instructively absent from the "build what you know" success narratives.

The Evidence: The Outlier Test

Here is the actual question hiding inside "should I build this for myself": is the reason you have this problem structural, or personal? A structural cause means the problem comes from something about the industry, the tooling, or the role — something anyone in a similar position would also run into. A personal cause means the problem comes from your specific circumstances, choices, or workflow quirks, and dissolves the moment those circumstances change.

You can't answer that from introspection alone, because you're inside the problem — that's exactly the vantage point that makes it hard to see which parts of your situation are typical and which are idiosyncratic. Run your idea against these conditions instead:

A row or two landing in the "outlier" column isn't disqualifying — most real ideas have at least one. But if most of the row lands there, you haven't found a market. You've found a very specific description of yourself. This is the same discipline behind the broader practice of problem discovery: separate the observation ("I have this problem") from the inference ("therefore other people have it too"), because the second half is where founders get sloppy.

Rob Fitzpatrick's The Mom Test makes essentially this same argument from a different angle: people are unreliable narrators of their own future behavior, and founders are unreliable narrators of their own representativeness. The fix in both cases is the same — stop asking whether the idea sounds good, and start collecting facts about what people actually do, today, without you in the room to bias the answer.

When It Works: Founder-Market Fit and a Reachable Population

Scratching your own itch works when two conditions hold together, not separately.

First, you need founder-market fit — a durable, earned reason you understand this market better than a founder who parachuted in after reading a trend report. That's not the same as liking the problem. It means you've absorbed the market's constraints, vocabulary, and unwritten rules through direct exposure, usually from doing the underlying job for money, not as a side interest. Founder-market fit is what turns a founder's itch into a shortcut instead of a distraction, because it lets you evaluate whether a proposed solution is realistic before you waste months building the wrong one. The concept is worth understanding on its own terms — see our deeper walkthrough of founder-market fit — but the short version is: your unfair advantage should be knowledge, not just motivation.

Second, you need a reachable population of people who share your situation — not demographically identical to you, but aligned on the dimensions that actually matter to the problem: same job function, same workflow, same constraints, same budget authority. "Reachable" is doing real work in that sentence. If the only way to find people like you is a coincidence — you happen to know them personally — you don't have a market, you have a friend group. If there's a community, a job title, an industry association, or a distribution channel where people who match your profile already congregate, you have a path to test the idea beyond your own opinion of it.

Rob Walling's Start Small, Stay Small is written almost entirely for this scenario: the solo or small-team founder who doesn't have venture money to buy their way past a lack of insider knowledge. Walling treats "solve your own problem" as one of the more dependable ways to generate a first idea for exactly this audience, precisely because it front-loads founder-market fit — but he pairs it with a hard requirement to confirm other people will pay before writing more code than a prototype needs. The itch gets you the idea. It does not get you a pass on confirming the idea is worth building.

The Implications: How to Validate an Itch Like Any Other Idea

Once you accept that the itch is a hypothesis, the practical shift is small but strict: treat your own idea with the same skepticism you'd apply to someone else's pitch.

That means, in order:

• Write down the specific claim your itch implies — not "people need better invoicing tools," but "freelancers who bill more than five clients a month lose real time reconciling payments across platforms." A vague itch produces a vague, unfalsifiable idea.
• Find people who match the "generalizes" column of the outlier test, and talk to them about their past behavior, not their opinion of your concept. Ask what they currently do about the problem, what it costs them in time or money, and what they've already tried and abandoned — the Mom Test framing again, because "would you use this?" gets you polite lies and "what did you do the last time this happened?" gets you facts.
• Look for evidence of an existing workaround, even a bad one. A spreadsheet, a manual process, a competitor's product used off-label — proof that someone is already paying a cost (in time, money, or annoyance) to deal with the problem is worth more than any amount of enthusiasm about your solution.
• Try to get a real commitment before you build much — a preorder, a paid pilot, a waitlist tied to a specific launch date, a signed letter of intent. Commitment separates people who have the problem from people who are just being nice to you in a conversation.

This is the same discipline that any idea should go through regardless of where it originated, and it's worth running end to end rather than skipping steps because the idea "feels personal" — our complete guide to startup idea validation walks through the full sequence if you haven't done it before. The only thing that changes when the idea started as your own itch is your confidence going in, and confidence is exactly the thing validation is supposed to test, not assume.

If the evidence holds up, you get to keep the speed advantage of building for yourself — fast iteration, an internal test user who cares, a founder who already understands the buyer — without the blind spot. If it doesn't hold up, you've just saved yourself from building an elaborate solution to a problem that only you have.

Key Takeaways

• An itch is a lead, not a validated market. It tells you a problem exists for one person. It says nothing about whether it exists for enough people to build a business on.
• Founder stories about personal problems usually hide an insider position. The companies people cite as proof "scratch your own itch works" were built by founders with deep, paid exposure to the market first — the itch was a symptom of that exposure, not a substitute for it.
• Run the outlier test before you build. Check why the problem exists, who else has mentioned it unprompted, how long you tolerated it, whether your resources match a real buyer's, and what's actually at stake for you versus them.
• Founder-market fit plus a reachable population of similar people is the condition that makes self-derived ideas work. Neither one alone is enough.
• Validate an itch-based idea exactly like any other idea — write the specific claim, talk to people about past behavior, look for existing workarounds, and get a real commitment before building more than a prototype.
• The itch buys you speed, not certainty. Use it to move fast on discovery, not as a reason to skip discovery altogether.

FAQ

Is it bad to build a product to solve your own problem?

No — it's a fast, cheap way to generate and stress-test an idea, because you get instant feedback from being your own first user. It becomes risky only when you stop there and treat your own satisfaction as proof that a broader market exists, instead of running the same validation you'd run on any other idea.

How do I know if I'm building for a real market or just for myself?

Run the outlier test: check whether the problem's cause is structural (an industry practice, a tooling gap) rather than personal to your setup, whether people outside your circle have mentioned it unprompted, and whether your resources and stakes resemble a typical buyer's. If most answers point back to your specific circumstances, you're likely the outlier.

What if I build something for myself and nobody else wants it?

That's a useful, fast outcome, not a failure of the idea-generation process — you found out early instead of after months of unpaid customer development. Treat it as a discovery-stage result: go back to the underlying problem, talk to a wider range of people who face it, and let a new, validated hypothesis replace the one that didn't hold up.