How to Find Customers on GitHub
If you sell a developer tool, GitHub is one of the most underrated places to find customers — and almost nobody works it deliberately. Every day, developers open issues describing a problem, a missing feature, or frustration with a tool they already use. Each one is a person telling you, in public, exactly what they need. This guide covers how to find those conversations and join them without being the annoying vendor.
Why GitHub beats most channels for dev tools
The intent on GitHub is unusually concrete. A Reddit post might say "any recommendations?" A GitHub issue says "the CLI hangs when I pipe more than 10k rows and I've tried X and Y" — that's a fully-qualified lead who has already scoped the problem, tried the alternatives, and is actively looking. Better still: the person is a developer, which for a dev tool means they can evaluate and adopt without a procurement cycle.
Where the buying intent lives
Four kinds of issues are worth watching:
- Feature requests on competitor repos — "would be great if [competitor] could also do Z." If your tool already does Z, that's a warm lead who has told you their exact gap.
- "Is there a tool that…" issues and discussions — people asking a project's community for a recommendation, often because the project itself won't add the feature.
- Frustration threads on popular repos — long issues where a workaround is being discussed is a signal that the built-in option isn't enough.
- Stale or "wontfix" issues — a maintainer declining to build something is an opening for a purpose-built tool that does exactly that.
Search GitHub like a buyer
Use GitHub's issue search and query the problem, filtered to issues. Search terms like "is there a tool" type:issue, "any alternative to" type:issue, or the specific pain your product removes. Sort by newest. A three-day-old issue with two comments and a real question is worth more than a 400-comment thread everyone has already piled into. The free GitHub search API returns exactly these results — it's how LurkScout scans GitHub for our customers.
How to engage without getting the vendor eye-roll
Developers have a finely-tuned spam detector. The rules that keep you welcome:
- Answer the actual technical question first — even if the answer has nothing to do with your product. Earn the right to be there.
- Disclose plainly that you built the thing: "full disclosure, I make X, so take this with salt." Developers respect it and quietly distrust anyone who hides it.
- Link to a doc or a specific solution, not your homepage. "Here's how we handle that exact case: [docs link]" beats a marketing URL every time.
- Don't comment on closed issues or necro-bump dead threads just to advertise — maintainers will flag it and it burns your reputation.
The hard part: doing it every day
Watching GitHub for the handful of issues that match what you sell means filtering thousands of issues across dozens of repos, catching them before the thread moves on, and reading enough of each to know if it's a real fit. That's the daily grind that makes the channel work — and the reason almost no founder does it consistently. This is exactly what LurkScout automates for developer-tool companies.
A realistic expectation
GitHub is a compounding, low-volume channel like the others — a few genuinely helpful comments a week, not a flood. But because the intent is so concrete and the audience is technical, the leads that do convert tend to convert fast. For dev-tool founders it's often the single highest-fit source LurkScout watches.