GitHub Issues as a Source of Micro SaaS Ideas

Reddit gets the attention, but the most precise description of what software fails to do is written down in issue trackers. A GitHub thread names the tool, the version, the steps, the workaround, and how many others hit the same wall.

It is also a trap. A bug in someone else’s product is not a product idea — you cannot sell a fix to a codebase you do not own. The value is in the requests the vendor decided not to build, and in the workarounds users describe in the comments.

Why Issue Trackers Read Differently

Issues differ from forum posts in ways that matter for research:

• They are specific. Not “this is annoying” but “re-importing 200 rows fails past column forty”. Specificity is what you turn into a spec later.
• They are dated and stateful. An issue still open after four years, or a maintainer writing “we will not fix this”, is a recorded decision rather than an opinion you have to interpret.
• They carry a cheap vote. Reactions let people agree without writing a comment, so the numbers are visible — and easy to misread.
• They come from invested users. Somebody who files a careful issue already uses the tool daily, which is closer to a paying customer than a survey respondent.

Searching for Demand, Not Bug Reports

GitHub’s issue search takes qualifiers, and a plain keyword search sorts by recency, the wrong order here. Start with the phrase plus a scope, then narrow:

• "invoice automation" in:title,body — restricts the words to where a problem gets described; in:comments finds the workarounds people post later.
• is:issue is:open — GitHub treats pull requests as issues by default, and a merged pull request is not a demand signal.
• comments:>20 — long threads mean a problem many people argued about, not one person venting.
• label:"help wanted" and label:wontfix — the first marks work the project wants and has not done; the second is the closest thing to a competitor announcing it will not compete there.
• created:>2024-01-01 — keeps out threads whose underlying tools no longer exist. Add org: or repo: when you already have a market in mind.

Sort results by reactions rather than date: the web interface offers it, and the search API takes sort=reactions on GET /search/issues. Sort first, then filter — an unfiltered phrase search sorted by reactions returns the loudest issues across all of GitHub, which usually have nothing to do with your topic. The type and state qualifiers are what turn that into a readable list. Unauthenticated search calls are rate-limited to a few requests per minute; a personal access token raises the ceiling if you script many queries in a row.

What Counts as Evidence

Not every thread in the list is a lead. The ones worth keeping look like this:

• The declined request. An issue asking for an integration or workflow the maintainers closed as out of scope, with a written reason. The reason tells you whether the gap is strategic or accidental.
• The described workaround. “I export to CSV, clean it in a spreadsheet and paste it back” is a specification. People pay to delete steps like that, and the steps name themselves.
• The setup question, asked repeatedly. “How do I get X to work with Y” is a product gap disguised as a support request, because the answer is a list of manual steps.
• Cross-repo repetition. The same missing step in unrelated projects points at a missing product rather than a missing commit.

What does not count: bugs in a product you do not control, requests that already shipped, and anything a maintainer is actively working on. That last one looks like demand and is really competition you would arrive late for.

Reading the Numbers Correctly

Reactions are a vote inside one repository’s community, a narrow and technical population. Thirty thumbs up on a developer tool issue does not mean thirty buyers; it means thirty people care enough to click, where clicking is cheap.

Three corrections keep you honest:

1. Count independent authors, not reactions. One issue with five commenters is weaker than the same complaint in five repositories.
2. Check the state before the count. A heavily reacted issue closed as completed describes a market that has been served. An open issue with a moderate count and a maintainer saying “not planned” is the better lead.
3. Separate product gaps from service gaps. Missing support hours and confusing documentation show up in trackers too. They are real pain, but a solo founder rarely beats a support team at support.

Keep counter-evidence in view as well. If the workaround is free software people describe as good enough, the demand exists but the willingness to pay does not. Willingness-to-pay signals are worth checking before you commit.

Turning a Thread into a Decision

Write one paragraph: the gap, who hits it, what they do today, and what the smallest product would be. Then test it against four questions.

• Does the same gap appear in more than one project, or is it one team’s edge case?
• Is the fix a product, or an hour of consulting you would have to deliver yourself?
• Can you name the workaround in the users’ own words?
• Is there evidence pointing the other way that you have not explained away?

If two of the four have no answer, you have reading material, not a decision.

Mistakes That Waste the Exercise

• Treating a popular repository as a market. Maintainers of a large open-source project are not your buyers, and their users have a strong preference for free.
• Reading only the newest issues. Older threads with a long discussion and a declined request carry more information than the last month of bug reports.
• Ignoring who wrote it. An issue from a hobbyist testing the tool locally is a weaker signal than one from an agency running it for clients.

Reading issues by hand works and does not scale: the qualifiers change per topic, and the interesting part sits in the comments. A research report starts from your topic, reads the same sources, and returns the recurring signals with the quotes kept checkable against the original thread. If you want the manual version, support forums and app store reviews are read the same way, and the source comparison explains when each one earns the effort. Start with finding pain points you can build on.

FAQ

Are GitHub issues a reliable demand signal?

They are the most precise written signal available and the least representative. Issue authors are technical, already using a tool, and rarely the person who signs off on a purchase. Use them to describe a gap, then confirm that the people who feel it also buy software.

Do I need an API key to search issues?

No. The public search API answers without authentication, with a low per-minute request limit. A personal access token raises it, which matters only if you run many queries in a row.

How many threads before I trust a pattern?

Enough that you can name independent sources for it: separate repositories, separate authors, and ideally a second source type such as a forum thread or a review. If all your evidence comes from one repository, you have found one team’s problem.

What if the vendor is already working on it?

Then you have found competition, not a gap. Note the request and its date, and move to the requests in the same tracker that were closed as out of scope — those are still open for someone else.