1. Write the problem in one sentence
Describe the pain, not the app. Name who has it and when. Example: "Engineering managers at 10 to 50 person teams lose track of PRs that sit unreviewed for days." If you can't name the job title and the moment it hurts, you are not ready to validate.
2. Search for people already complaining
Search GitHub Issues, Hacker News and Reddit for the pain in their words. Try GitHub search queries like "stale pull requests" or "CODEOWNERS not working", and on Hacker News search hn.algolia.com for "PR review bottleneck". Check r/devops, r/ExperiencedDevs and r/github. Save every thread with a real person describing the problem.
3. Check the GitHub Marketplace and Actions
Browse github.com/marketplace and search for apps and Actions solving the same thing. Read their reviews, open issues and star counts. Complaints in competitor repos tell you what is still broken. No competitors at all can mean no demand, so look harder before celebrating.
4. Reach out to 20 specific people
Find people who opened or commented on related issues, or who maintain repos where the problem shows up. Message them on the email in their GitHub profile, on X, or on LinkedIn if they list an engineering lead role. Example: "Saw your comment on stale PRs in the X repo. How do you handle that today? I'm researching it, not selling anything." Aim for 5 calls.
5. Ask about the past, not the future
On calls, ask what they did last time the problem happened, what it cost them, and what they tried. Skip "Would you use this?" since everyone says yes. Good questions: "When did this last bite you?" and "Did you build a script or bot for it?" A homemade workaround is a strong signal.
6. Post where maintainers and team leads hang out
Share the problem, not a pitch, in places like the DevOps Discord servers, Rands Leadership Slack, dev.to, or a Show HN once you have a mockup. Ask how others solve it. Reply to everyone and invite the most engaged to a call.
7. Ask for a commitment
Build a one-page site with the problem, a screenshot mockup and a button to join a pilot or pre-pay. Send it to the people you spoke with. Example: "I'm building this for teams like yours. Want to be one of 5 pilot repos? It's $20 a month once it works." A pilot install date, a card number or an intro to their manager counts. A compliment does not.
8. Decide and keep going daily
If 3 or more people commit, build the smallest version that solves their exact case. If nobody does, narrow the job title or the problem and repeat. Hulby, an AI cofounder, does this outreach and follow-up daily for founders so the conversations keep happening.
Mistakes to skip
- Building the app first and hoping installs show up from the Marketplace listing.
- Asking friends and coworkers who will be polite instead of honest.
- Treating stars on a demo repo as proof people will pay.
- Targeting "developers" in general instead of one role on one kind of team.
Want this done for your GitHub app, every day?
Hulby finds the people asking for what you built, writes every reply and email, and keeps you on it until they pay. Free to start.
Find my first customersQuestions
How many conversations do I need?
Five to ten with the right people usually shows a clear pattern. Stop when you hear the same pain repeated.
Should I target individual developers or companies?
Whoever feels the pain and controls the install. For paid apps that is often an engineering manager or org admin, not an individual contributor.
Is it rude to message people from GitHub issues?
Not if you are brief, reference their specific comment and ask a real question. Don't mass message or pitch.
What if my app is free?
Still ask for a commitment, like installing a pilot on a real repo this week. Time and access are a cost too.