How to find startup ideas as a developer

Developers have an advantage almost nobody talks about when it comes to finding startup ideas: they already spend their day inside the exact places where technical pain gets written down. The problem isn't access — it's that most of that pain scrolls past as noise. Learning to read it as demand, rather than as background chatter, is the entire skill.

The "scratch your own itch" trap

Scratching your own itch is the most repeated advice in startup circles, and it's genuinely good advice — for a narrow set of cases. It works when the itch is shared by a large, well-defined group of people who are not you, and who would pay to have it solved. It fails, constantly, when the itch is a quirk of your own stack, your own team's conventions, or your own taste in tooling. That's how you end up with a beautifully engineered dotfiles manager that only you and three coworkers will ever use.

The tell that separates the two: can you find *other people*, unconnected to you, independently describing the same pain in public? If your itch shows up as a recurring complaint across communities you don't participate in, it's a market. If it only shows up inside your own head, it's a preference — build it for fun, but don't quit your job over it.

Where developers should actually be looking

Most idea-hunting advice is written for non-technical founders and points them at generic complaint forums. Developers have better sources available, because they can participate in — and understand — communities that are effectively closed to outsiders:

• GitHub Issues. Feature requests with dozens of thumbs-up reactions, "is there a tool for X" comments buried in unrelated repos, and abandoned issues where maintainers said "not planned" are some of the highest-signal, least-competed-for leads available. Someone already built half the case for you.
• Hacker News — Ask HN and Show HN. Ask HN threads ("Ask HN: How do you handle...") surface unsolved workflow problems directly from a technical audience. Show HN comment sections are even better: read what people criticize about a launched product, not what they praise. Criticism is a feature-request in disguise.
• Lobsters. Smaller and more technical than Hacker News, with a userbase skewed toward practicing engineers rather than founders. Pain discussed here tends to be closer to the metal — infra, tooling, developer experience — and less picked-over by other idea-hunters.
• Stack Exchange's softwarerecs tag. This is arguably the purest solution-seeking signal on the internet: people explicitly asking "is there software that does X," with structured answers and vote counts showing how many others share the need.
• r/webdev, r/devops, r/sysadmin, r/ExperiencedDevs. Professional subreddits where the posters are working engineers, not hobbyists — which matters, because their time is worth money and their frustration usually maps to a budget line somewhere.

Reading technical pain as buyer intent

The skill that separates developers who find real ideas from developers who find interesting-but-unfundable trivia is learning to read pain the way a salesperson reads a sales call — for intent, not just content. A GitHub issue that says "this would be nice" is weak. An issue where five different companies comment "we built an internal workaround for this and it's fragile" is strong — it tells you the pain is expensive enough that people already paid for it with engineering time, which is the closest thing to a receipt you'll find in a technical forum.

Watch specifically for language that signals switching or workaround behavior: "we ended up rolling our own," "we pay for [competitor] but it doesn't handle X," "I wrote a script for this and it breaks constantly." These phrases show up constantly in developer communities and rarely get mined, because most idea-hunting guides only look at consumer-facing complaint sources like app reviews and Reddit rants. Developers reading developer forums are looking in a place most non-technical founders can't even access — buyer-intent signals: the phrases that predict willingness to pay breaks down which phrases matter most, and the same ladder applies whether the source is a subreddit or a GitHub thread.

The best developer startup ideas aren't invented in a vacuum — they're extracted from a thread you already had open in another tab.

Validating as a developer: build a fake door or an OSS wedge

Developers have a validation shortcut most founders don't: they can ship something real, fast, without a team or a budget. Use that advantage instead of skipping straight to a full product.

A fake-door test for a developer tool can be a single landing page with a real signup form and no backend — post it in the exact community where you found the pain and watch the conversion. An open-source wedge is even stronger: ship a narrow, genuinely useful CLI tool or library that solves the smallest slice of the problem, publish it where the original complaints live, and see whether strangers star it, open issues, or ask for a hosted version. Both approaches cost a weekend, not a quarter, and both generate the same thing — real behavior from real strangers, which is worth more than any amount of hypothetical enthusiasm from friends. For a broader framework on separating a real opportunity from a fun side project, see how to come up with SaaS ideas: the complete guide.

The takeaway

You don't need a better idea-generation technique than the one you already have access to. You need to stop treating GitHub issues, HN threads, and Stack Exchange tags as background noise and start reading them as a live feed of buyer intent — then validate the strongest signals the way you'd validate any technical hypothesis: by shipping something small and measuring what happens.