How to Find SaaS Ideas From Customer Complaints

Many SaaS products begin with a problem that someone is already trying to solve.

It might be a repetitive task, a frustrating workflow, an unreliable feature or a process that still depends on spreadsheets and manual work.

These problems often appear in places where people discuss their work: software reviews, community discussions, feature requests, public issue trackers and customer feedback.

For a developer looking for a product idea, these complaints can be useful research leads.

But there is an important distinction: a complaint is evidence that someone has a problem or wants something changed. It is not proof that a profitable SaaS opportunity exists.

The goal is to find complaints, understand the underlying problem, identify patterns across independent sources and turn promising findings into testable product hypotheses.

This guide explains how to do that without treating every negative comment as a business opportunity.

Why Customer Complaints Can Reveal SaaS Ideas

People often describe problems more clearly when they explain what is frustrating about their current workflow.

Consider the difference:

• “I need an AI productivity app.”
• “I have to copy information from three different tools into a spreadsheet every morning.”

The first statement describes a product preference. The second gives you something to investigate: a task, a workflow and a possible source of wasted effort.

Complaints can reveal several kinds of problems:

Complaint type	What it may reveal
Repetitive manual work	A workflow that could potentially be simplified
Missing functionality	A task existing software does not support in the desired way
Poor integrations	Information or work is fragmented across tools
Confusing workflows	Users struggle to complete an important task
Unreliable processes	People need more predictable results
Expensive alternatives	Customers may be looking for a different cost or service model
Slow or difficult processes	Time and operational effort may be involved

This approach is consistent with Paul Graham’s advice in How to Get Startup Ideas. His essay, published in November 2012, argues that founders should pay attention to real problems rather than simply inventing plausible startup concepts.

However, complaints have limitations. People may complain about features they would never pay for. A vocal user may not represent a wider customer segment. A problem may be annoying but not important enough to justify changing software.

Treat complaints as starting points for research, not ready-made business ideas.

Step 1: Choose a Customer Segment or Workflow to Investigate

Do not start by searching the entire internet for random complaints.

That approach produces a large collection of disconnected problems without telling you who experiences them or whether you understand their needs.

Start with a domain or customer group.

For example:

Customer segment	Workflows to investigate
Small agencies	Client approvals, project updates, reporting and invoicing
E-commerce stores	Inventory, returns, order tracking and product listings
Freelancers	Proposals, payments, contracts and client communication
Software teams	Deployment, testing, monitoring and issue tracking
Local service businesses	Appointments, reminders, scheduling and customer records
Content teams	Research, editing, approvals and publishing

Choose a segment where you can understand the work or reach people who perform it.

You do not need to be an expert in the industry before beginning. You do need enough context to ask sensible follow-up questions.

Define the person and the workflow

Write down three things:

1. Who might experience the problem?

For example, a small agency owner, operations manager, developer or independent consultant.

2. What are they trying to accomplish?

For example, collecting approvals, reconciling payments or tracking recurring tasks.

3. Where might the problem appear?

For example, product reviews, support discussions, public issue trackers or conversations in professional communities.

This gives your research a direction.

Step 2: Find Places Where People Describe Their Problems

Complaints appear in different places. Each source has a different type of information and a different limitation.

A. Software review platforms

Review platforms can help you understand how customers experience existing products.

Useful places to investigate include:

• G2
• Capterra
• Relevant software marketplaces
• Product-specific review pages

Look for reviews discussing recurring workflows, missing functionality, difficult setup, integrations and workarounds.

Do not read only the lowest-rated reviews. Positive reviews can also reveal what customers value, while mixed reviews may explain where a product works well for one segment but not another.

G2 describes a review moderation process involving manual moderation, reviewer sign-in and additional checks. These measures can improve confidence in the review process, but they do not turn every review into an objective or representative assessment of the entire market. Read each review as an individual’s account. See How G2 ensures authentic reviews.

For a deeper guide to extracting patterns from G2 and Capterra reviews, see the planned IDE-006 article. This article covers the broader discovery method rather than reviewing one platform in detail.

B. Online communities and discussion forums

People also discuss frustrating workflows outside review platforms.

Depending on your target audience, useful places may include:

• Reddit
• Indie Hackers
• Hacker News
• Professional forums
• Industry-specific discussion communities

Look for conversations where users explain how they handle a task, what repeatedly goes wrong or why their current tools are insufficient.

Pay attention to the full discussion rather than just the original post. Replies may reveal that other people have the same problem, that a proposed workaround already exists, or that the issue is specific to one user’s setup.

Important: follow each platform’s rules. Reddit’s current policies prohibit scraping without an authorised agreement and accessing or collecting data without permission. Its developer documentation also says commercial use of its developer tools and services requires prior permission, with a contract required for commercial use of Reddit data. Do not build an unauthorised scraper or assume that public posts can automatically be copied into a commercial product or monetised website. Check the Reddit access and commercial-use guidance and Don’t break the site policy.

For the specific process of researching Reddit communities, the planned IDE-005 article will cover that channel separately.

C. Public issue trackers and feature requests

Software issue trackers are another useful source.

Developers and users may report:

• Missing functionality
• Difficult workflows
• Repeated bugs
• Integration problems
• Requests for more control
• Limitations that affect how a tool is used

Places to investigate include public GitHub repositories, GitLab projects and product-specific feature-request boards.

For example, a request for an additional sorting option may reveal more than a desire for one new button. It may expose a larger workflow issue involving how users organise and navigate their projects.

Not every issue tracker is publicly accessible, and not every request represents an independent customer. Check the source’s context and permissions before using information from it.

D. Customer support and your own work

If you have legitimate access to support tickets, help-desk records or customer feedback, these can be particularly useful.

You may already have direct access to the people experiencing the problem and the context in which it occurs.

Potential sources include:

• Support tickets
• Product feedback forms
• Sales conversations
• Customer onboarding questions
• Repeated requests to your team
• Your own professional workflow

Only use customer information you are authorised to access. Respect confidentiality, privacy obligations and any applicable data-processing restrictions. Do not publish private customer messages or identifying details without permission.

These sources are useful because they may provide more context than a short public comment.

Step 3: Search for Problem Language

Once you have chosen your sources, search for language that describes an actual difficulty.

A useful starting point is to search around tasks, workarounds and failed outcomes rather than only searching for product names.

Examples include:

Search phrase	What it may uncover
“I have to manually…”	Repetitive work
“How do you handle…”	Unresolved workflow questions
“There is no way to…”	Missing functionality
“Doesn’t support…”	Product limitations
“We currently use a spreadsheet…”	Manual workarounds
“I wish this could…”	Desired improvements
“This keeps breaking…”	Reliability problems

These phrases are discovery prompts, not proof that a market exists.

A person asking how to do something may already have a perfectly acceptable solution. A feature request may have little importance outside the individual who submitted it.

Search around the job, not just the complaint

Suppose you are researching small agencies.

Instead of searching only for “agency software complaints”, investigate individual workflows:

• Collecting feedback from clients
• Tracking pending approvals
• Preparing recurring reports
• Managing project handovers
• Recording revisions
• Following up on unpaid invoices

This can reveal problems that users do not describe using the phrase “I need new software.”

It also helps you discover needs that are currently handled with ordinary tools rather than a dedicated SaaS product.

Step 4: Record Complaints Without Losing Their Context

Do not collect complaints in a random notes file and expect useful patterns to appear later.

Create a simple evidence ledger.

For every useful complaint, record:

Field	What to capture
Source	Platform, website or conversation
Original link	Direct URL to the source
Date observed	When you accessed it
Customer segment	Who appears to experience the problem
Workflow	What the person was trying to do
Complaint	A short, accurate summary
Existing workaround	What the person currently does
Impact	Any stated time, cost, delay or risk
Evidence type	Request, frustration, workaround or observed behaviour
Confidence	Initial assessment and unanswered questions

Preserve the source link so you can return to the original context.

Do not copy large portions of reviews or community posts into your research database. A short summary and a link are usually enough. Avoid recording personal information that is not needed for the research.

Separate what the person said from what you infer

Imagine a review says:

“The reporting process takes too long, and we still have to export the data into a spreadsheet.”

You could record it as follows:

Element	Observation
Reported complaint	Reporting takes too long
Reported workaround	Data is exported to a spreadsheet
Possible underlying problem	The reporting workflow may not provide the required output
What is unknown	How frequently this happens and how important it is to the buyer

Notice the difference between an observation and an interpretation.

The review supports the claim that one reviewer described a slow process and a spreadsheet workaround. It does not prove that every customer has the same problem or that a separate reporting SaaS would succeed.

Step 5: Turn Individual Complaints Into Underlying Problems

This is the most important reasoning step.

A complaint often describes a symptom. Your job is to understand the work the person is trying to complete.

Consider the following examples:

Complaint	Possible underlying problem
“I have to export everything manually.”	Information may not move easily between systems
“There are too many steps to approve a project.”	The approval workflow may create unnecessary coordination
“I keep losing track of updates.”	Relevant changes may not be visible at the right time
“The same information has to be entered twice.”	Multiple systems may require duplicate data entry
“I cannot organise these items properly.”	The product may lack the organisation options the user needs

These interpretations are hypotheses. They need to be checked against the original source and, where possible, other users.

Ask five questions about each complaint

1. What was the person trying to accomplish?
   Identify the actual task or desired outcome.
2. What went wrong?
   Describe the specific obstacle rather than repeating a vague statement such as “the software is bad.”
3. What do they do instead?
   Look for manual work, another product, a service or a workaround.
4. What happens because of the problem?
   Record any stated delay, cost, repeated work or missed outcome.
5. Who else might experience the same problem?
   Identify the potential customer group without assuming that the problem is widespread.

You should now be able to describe the problem without mentioning your proposed software.

For example:

“Small project teams that organise work using coloured project groups may struggle to keep their navigation consistently sorted when their current tool only supports manual ordering.”

This is more useful than saying:

“I should build an AI-powered project management dashboard.”

The problem statement gives you something specific to investigate.

Step 6: Look for Repeated Patterns Across Independent Sources

One complaint can be useful. A repeated problem across unrelated people and sources deserves more attention.

However, repetition needs to be checked carefully.

Ten comments do not necessarily mean ten independent customers. They may be:

• The same person posting in several places
• Reposts of one original complaint
• Replies from people discussing the same incident
• Several users copying an existing feature request
• Comments about the same product-specific bug

Do not count these as independent evidence without checking.

Cluster complaints by the underlying workflow

Group complaints according to the job or difficulty they describe, not just similar words.

For example:

Complaint	Underlying workflow	Possible cluster
“I have to update the spreadsheet manually.”	Updating operational data	Manual data synchronisation
“The same information is entered twice.”	Maintaining records	Duplicate data entry
“Changes do not appear in the other tool.”	Keeping systems consistent	Data synchronisation
“I have to check both dashboards.”	Monitoring related information	Fragmented workflows

These complaints may belong to one broader problem area even though the wording is different.

On the other hand, two complaints mentioning “notifications” may have entirely different causes and customer needs.

Look for evidence strength, not a magic complaint count

There is no universal number of complaints that makes a product opportunity real.

Use the following evidence levels as a way to organise your findings:

Evidence level	What you have found
Initial lead	One relevant complaint or request
Repeated pattern	Similar problems from independent users
Behavioural evidence	People describe workarounds or actions they already take
Impact evidence	The problem has a specific operational, financial or time-related consequence
Commercial evidence	Relevant buyers show meaningful willingness to commit resources or pay

This is a research framework, not a scientifically validated scoring system.

The higher levels give you a stronger reason to investigate, but even several independent complaints do not automatically establish a viable market.

A Worked Example: From a Public Feature Request to a Product Hypothesis

Here is one real example of how a public complaint can become a research lead.

On August 20, 2026, a user opened GitHub issue #3573 in the Vikunja project.

The request concerns automatic or fixed sorting options for the project’s sidebar.

The issue describes how the sidebar currently relies on manual ordering. The reporter explains that when projects are colour-coded, maintaining a consistent visual grouping can become difficult because changes to the project list may require manually dragging items back into place. The requested options include alphabetical and colour-based sorting.

This is a useful example because the source describes both the problem and the current workaround.

Extract the evidence

Research field	Finding
Source	Public Vikunja GitHub issue #3573
Date opened	August 20, 2026
Customer task	Organising projects in the sidebar
Reported limitation	Sorting is based on manual ordering
Reported difficulty	Keeping the project list aligned with colour-based organisation
Workaround	Manually reordering projects
Requested improvement	Automatic or fixed sort modes
Missing evidence	Number of affected users, frequency, financial impact and willingness to pay

Separate the complaint from the opportunity

The complaint suggests a possible underlying problem:

People who organise projects using colours or categories may want their navigation order to remain consistent without repeatedly adjusting it manually.

A possible product hypothesis might be:

“Teams that organise large project lists using visual categories may need a more predictable way to sort and navigate their projects.”

But this does not yet establish a SaaS opportunity.

The issue is one public feature request. It does not tell us how many users experience the problem, whether the existing product will implement the feature, how often the issue occurs or whether anyone would pay for a separate solution.

Our research decision: keep this as a lead, not a validated idea.

The next step would be to look for independent users with the same workflow, examine existing alternatives and investigate whether the problem matters enough to justify a separate product.

That is the difference between finding a complaint and discovering a business opportunity.

Step 7: Filter the Promising Problems Before Adding Them to Your Idea Backlog

After gathering and clustering complaints, you may have several possible problem areas.

Do not immediately turn every cluster into a product concept.

Use a simple review table.

Question	Why it matters
Is the affected customer identifiable?	You need to know who might use the product
Does the problem occur repeatedly?	One unusual incident may not justify a product
Is the workaround inconvenient?	A problem with no meaningful friction may not create demand
Does it have a real consequence?	The problem needs enough importance to deserve attention
Is there an existing budget or spend?	Existing spending can help reveal commercial relevance
Can you reach these customers?	A good problem is difficult to serve if buyers are inaccessible
Are existing alternatives sufficient?	You need to understand why customers might switch
Can a small team realistically solve it?	The opportunity must fit your resources and capabilities

You do not need to assign arbitrary numerical weights to every answer.

Record what you know, what you do not know and what evidence would change your assessment.

Keep rejected ideas in the research log

A useful research process should preserve ideas that you decided not to pursue.

For example:

Candidate problem	Why it looked interesting	Why it was not promoted
One missing sorting option	A public user described a concrete workflow issue	Only one complaint found; buyer impact and wider demand unknown
A manual reporting workflow	Could involve repetitive work	Existing alternatives and willingness to pay not yet understood
A missing integration	May indicate fragmented workflows	The affected customer segment is not yet clear

These are example research-log entries, not findings from a completed market study.

Recording why a candidate was rejected helps prevent the same weak idea from repeatedly returning to your backlog.

From Customer Complaint to an Idea Worth Validating

Once a problem has a clear customer, workflow and supporting evidence, you can write a product hypothesis.

Use this template:

[Customer segment] struggles with [specific problem] when [situation]. They currently use [workaround or alternative]. A possible product could help them achieve [desired outcome] by [proposed approach].

For example:

“Small agencies that manage multiple client projects struggle to keep approval status and feedback organised across separate conversations. A possible product could give them a single workflow for tracking feedback, pending approvals and client decisions.”

This is a hypothesis, not a product specification.

Do not start adding features until you understand the customer’s actual problem.

At this point, move the candidate into your idea backlog with its supporting evidence, unanswered questions and source links.

Then proceed to validation.

The next question is no longer “Can I think of a product for this?” It is “Do the right customers experience this problem often enough to change their behaviour or pay for a better solution?”

That is where the broader process in How to Validate a Micro-SaaS Idea Without Building It fits. Confirm that IDE-001 is live at that URL before adding the link in WordPress.

Copyable Customer Complaint Research Worksheet

Use this template whenever you find a possible SaaS problem.

1. Research context

• Research domain:
• Target customer segment:
• Workflow being investigated:
• Date research started:
• Why this segment was selected:

2. Complaint record

• Source platform:
• Direct source URL:
• Date of original complaint:
• Date observed:
• Customer type:
• Short complaint summary:
• What the customer was trying to do:
• Existing workaround:
• Reported impact:

3. Problem interpretation

• Underlying problem:
• Possible cause:
• Desired customer outcome:
• What is observation versus interpretation?
• What remains unknown?

4. Pattern research

• Independent sources found:
• Repeated problems:
• Different customer segments affected:
• Duplicate or related complaints removed:
• Contradictory evidence:
• Current alternative solutions:

5. Opportunity assessment

• Identifiable customer:
• Frequency of the problem:
• Importance or impact:
• Existing spending or workaround:
• Reachability of potential buyers:
• Possible product hypothesis:
• Largest unanswered question:

6. Decision

• Research status: Lead / Repeated pattern / Ready for validation / Rejected
• Reason for decision:
• Next research action:
• Should this enter the product idea backlog? Yes / No

Keep the original links with the worksheet. A complaint without its source and context becomes difficult to verify later.

Frequently Asked Questions

Final Thoughts

You do not need to invent a SaaS idea from nothing.

Useful product opportunities can begin with problems people are already discussing, workarounds they already use and tasks they repeatedly struggle to complete.

But collecting complaints is only the first part of the job.

Understand the customer. Identify the actual workflow. Compare independent sources. Separate facts from assumptions. Keep rejected ideas in your research log.

Most importantly, do not confuse a requested feature with a validated business opportunity.

Find the complaint. Understand the problem. Look for the pattern. Then investigate whether it is worth solving.

---

Sources and Further Reading

1. Paul Graham — How to Get Startup Ideas, November 2012.
2. Vikunja — GitHub Issue #3573: Automatic/fixed sort options for project sidebar, opened August 20, 2026.
3. Reddit Help — Developer Platform and Accessing Reddit Data, updated May 28, 2026.
4. Reddit Help — Don’t break the site, updated October 6, 2026.
5. G2 Documentation — How G2 ensures authentic reviews, published September 18, 2025.

The GitHub issue is a single public feature request used to demonstrate the research method. It is not evidence of market size, customer demand or willingness to pay. The sample research-log entries are illustrative, not findings from an IndieOS market study.