Most people who build something nobody buys didn't build it badly. They built it early, before they had proof that anyone cared enough to pay. The fix is a short process you run before you write code: find evidence of demand, look for signs people will spend money, and talk to those people directly.
This guide walks through that process step by step. You can do all of it by hand, though it takes more time than using a research tool.
Start with a problem, not an idea
An idea is a guess about what someone might want. A problem is something a person has already said out loud, usually while annoyed.
If you start with "I should build an invoicing app," you spend your energy defending the idea. If you start with "freelancers keep complaining about chasing late payments," you spend your energy checking whether the complaint is real, frequent and costly.
That shift changes what you search for. You stop asking "is my idea good?" and start asking "who has this problem, how bad is it, and what are they doing about it today?"
Where to look for real problems
The best sources are places where people describe their work without trying to impress anyone:
- Community forums and subreddits for a profession or hobby
- Support threads and reviews of existing tools
- Job posts that describe a painful manual task
- Your own past work, if you have industry experience
People on forums complain honestly. They also describe the problem in their own words, which helps later when you write a landing page.
Gather demand evidence you can check
One complaint is an anecdote. A pattern is evidence. You want to see the same problem described by different people, in different threads, over time.
For each problem you're considering, write down:
- The exact words people use (copy them verbatim)
- A link to where they said it
- How many separate people said something similar
- How recent the posts are
- What they say they tried already
Keep the quotes exact. Paraphrasing quietly turns what people said into what you wish they said.
Two real examples of what evidence looks like
Here is a post from r/sysadmin about identity cleanup after a company acquisition: "8 months post-acquisition and we still have 200 people with active accounts in both tenants. Some line-of-business apps were never migrated."
Notice what makes this useful. It has a time frame (eight months), a count (200 people), and a reason the work stalled (apps never migrated). That is a business problem with a cost attached, not a vague gripe.
And here is a different kind of problem, from a thread in r/entrepreneur about agency work: "Every time i took on a new client i was doing the same manual analysis over and over. Go through their website, check the SEO, read the copy, look at competitors, figure out where they're leaking money."
This one describes a repeated task, which is a good sign. Repetition is where software and productized services tend to fit. Still, it is one person's account. You would need to find more people describing the same chore before treating it as a pattern.
Separate venting from willingness to pay
This is the hardest part, and it's where most research falls apart. Plenty of people complain about things they would never pay to fix. A complaint shows pain. It doesn't show a budget.
Look for signals that someone is already spending time, money or status on the problem.
Signals that suggest people will pay
- They already pay for a workaround. A spreadsheet service, a freelancer, an expensive tool they dislike.
- They name a cost. Hours lost, clients lost, fines, delayed revenue.
- They ask for recommendations. "What do you use for X?" means they are shopping.
- They complain about the price of current options. That means they accept paying, just not this much.
- The problem touches revenue or risk. Money-making and money-losing problems get budget faster than annoyances.
- They are a business, not a hobbyist. Companies have budgets and expense accounts.
Signals that suggest they won't
- The complaint is about something they do for fun
- Nobody mentions trying any solution
- The problem happens rarely
- The audience has little money and many free alternatives
No single signal settles it. You are building a case. A problem with high intensity, high frequency and some sign of spending is a stronger candidate than one with only a loud complaint.
A simple scoring sheet
If you track candidates by hand, score each from 1 to 5 on three questions:
- Intensity: How upset or blocked are people?
- Frequency: How often does the problem come up, and how many people mention it?
- Willingness to pay: Is there evidence of money or time already spent?
Add the scores. Anything weak on all three drops off the list. Anything strong on one but weak on willingness to pay needs a closer look before you commit.
Talk to the people who posted
Reading is not enough. Before building, you need conversations. The goal isn't to pitch. It's to understand the problem better than anyone else who might build for it.
People who post about a problem are often happy to talk about it, especially if you are polite and clear about why you are writing. Keep the first message short and honest. Say where you saw their post, that you are exploring the problem, and ask for a brief chat. Make it clear you aren't selling anything.
Questions worth asking
Stick to the past and the present, not hypotheticals:
- "Tell me about the last time this happened."
- "What did you do about it?"
- "What did that cost you, in time or money?"
- "Have you tried any tools or services? What went wrong?"
- "Who else is involved when this comes up?"
- "If this went away tomorrow, what would change?"
Avoid "Would you buy this?" Almost everyone says yes to be kind. Ask about what they have already done instead. Behavior is better evidence than opinion.
What a good conversation tells you
Listen for specifics: tools they use, who approves spending, how often the problem returns. If five people describe the same workaround in different words, you have found something real. If every answer is different, the problem may be too scattered to build for yet.
Test a small commitment before you build
After research and conversations, you should have a short list, ideally one problem, with a clear audience. Now test whether people will take a small step toward paying.
Options, from lightest to heaviest:
- A landing page that describes the problem in the words you collected, with a waitlist
- A manual service where you solve the problem by hand for a few people
- A paid pilot at a small price, even before the product is finished
- A pre-sale if your audience is a business with clear needs
A manual service is underrated. If you can solve the problem yourself with spreadsheets and email, you learn what the real workflow is. You also find out whether people pay. If they won't pay for the hand-built version, they probably won't pay for the automated one.
Decide in advance what counts as success. For example: "Three of ten conversations lead to a paid pilot." Pick your own number, but write it down before you see results so you don't talk yourself into a pass.
Where a research tool can save time
Doing this manually works, but the digging takes time. Reading threads, copying quotes, checking dates and sorting by how serious each problem is adds up.
SaasNiche is one tool built for this stage. It scans Reddit communities to surface pain points, each scored 0–100 for intensity, frequency and willingness to pay, and backed by verbatim user quotes. It also generates AI solution ideas in SaaS, productized service and info product formats, and lets you message the original posters for customer discovery.
A tool like this doesn't replace your judgment. A score is a starting point for deciding what to read closely. You still need to click through to the source, read the thread and talk to people.
A one-week plan
If you want a concrete schedule, try this:
Days 1–2: Collect. Pick one audience. Gather 15 to 20 problem statements with exact quotes and links.
Day 3: Score. Rate each on intensity, frequency and willingness to pay. Cut to three.
Days 4–5: Talk. Message people who posted about your top three. Aim for a handful of short calls.
Day 6: Choose. Pick the problem where people described real spending, repeated pain and a clear buyer.
Day 7: Test. Put up a landing page or offer a manual version to the people you spoke with.
At the end of the week you will have a clearer view of whether the problem is worth building for.
Common mistakes to avoid
- Falling in love with the idea. Stay attached to the problem instead.
- Counting compliments as demand. "Cool idea" is not a purchase.
- Researching forever. Set a deadline, then talk to people.
- Building for everyone. A narrow audience with a sharp problem beats a broad one with a mild problem.
- Skipping the source. Always read the original thread, not just a summary of it.
Start with the evidence
Building something people pay for comes down to order of operations: problem first, evidence second, conversations third, a small paid test fourth, and code last. If you want to speed up the first steps, you can browse scored Reddit pain points and their source quotes in SaasNiche, which offers a 7-day trial on the $19/month Starter plan.
FAQ
How do I know if people will pay for my idea?
Look for behavior, not opinions. People already paying for a workaround, naming a cost in time or money, or asking for tool recommendations are stronger signs than compliments. The most reliable test is a small commitment such as a paid pilot, a pre-sale or a deposit.
How many customer conversations do I need before building?
There is no fixed number. A common approach is to keep talking until the answers start to repeat, meaning new people describe the same problem, workaround and cost. If every conversation sounds different, the problem may be too scattered. A handful of focused calls is often enough to see whether a pattern exists.
Is Reddit a good place to find product ideas?
It can be. People describe problems in their own words and often explain what they tried. The limits are that posts show only a slice of a market and that complaints don't always mean people will pay. Treat posts as leads to investigate, then confirm with direct conversations.
What is the difference between a pain point and willingness to pay?
A pain point is a problem someone is frustrated by. Willingness to pay means they would spend money to solve it. Many painful problems fail this test because they happen rarely, affect people with little budget, or already have free solutions.
Should I build an MVP or validate first?
Validate first, in small steps. A landing page, a manual service or a paid pilot can all test demand without a full product. An MVP is more useful once you know who the buyer is and what they will pay for.