Most indie hackers still pick ideas by vibes.

You see a cool product, copy the pattern, or wake up with a “genius idea” and only then start asking, “does anyone even want this?”

Demand discovery is the opposite: you start from evidence of real demand and only pick ideas once you’ve seen enough pain in the wild.

This guide walks through a practical demand discovery workflow you can run in a few hours per week. It’s built for indie hackers and lean teams who want stronger demand signals before they build, with or without tools like Miner helping automate the research.

What “Demand Discovery” Actually Is (For Indie Hackers)

For this article, think of demand discovery as:

Systematically finding and tracking real, repeated problems and buying intent before you commit to an idea.

It is not:

• Idea brainstorming – coming up with clever products in a vacuum.
• Late-stage validation – A/B testing a landing page after you already picked an idea and half-built it.

Demand discovery for indie hackers sits in between:

1. You define your constraints and the kinds of customers you like.
2. You go hunting for evidence of existing demand: complaints, hacks, “what tool should I use?” threads, people throwing money at bad solutions.
3. You log and compare these signals until a few problems clearly stand out.
4. Only then do you spin up small experiments around specific problems.

The mindset shift: you’re not hunting for “ideas”; you’re hunting for hot problems with real demand that you can later express as ideas.

Why Indie Hackers Need Demand Discovery (Not Just Ideas)

A few common patterns:

• You copy what worked for someone else (e.g., “Notion for X”, “Stripe for Y”) without understanding why customers actually bought.
• You confuse novelty with demand: “nobody is doing this yet” feels like a good sign, but often means nobody cares.
• You skim Reddit/X, see scattered complaints, and can’t tell what’s real signal versus one-off rant.

Demand discovery fixes this by:

• Forcing you to look at behavior and pain, not just opinions.
• Collecting signals over time so you can see repetition and intensity.
• Giving you a simple way to compare problems instead of falling in love with the first interesting one.

You still get to be creative, but inside the boundaries of what people clearly care about.

Step 1: Clarify Your Constraints Before You Hunt For Demand

Before you start scrolling Reddit for hours, decide what you actually want to find.

You’re not looking for “any problem”; you’re looking for a problem you can realistically solve.

Answer these for yourself:

• Skills: What can you credibly build or deliver in 4–8 weeks? (e.g., “web apps with Stripe”, “Chrome extensions”, “data scraping and reports”, “consulting + automation”.)
• Capital: How much cash and runway do you have? (e.g., “$0, must be profitable asap” vs. “12 months runway, okay with slower monetization”.)
• Time: How many hours per week can you put in?
• Market preferences: Who do you want to serve? (e.g., SaaS founders, HR, creators, devs, ecom, agencies.)
• Business model comfort: What are you fine with? (SaaS, info products, services, usage-based, etc.)

Turn this into a short “search charter”:

• “I’m looking for problems experienced by B2B SaaS founders where I can solve it with a small web app or data/reporting product.”
• “I’m looking for recurring pains for creators or indie hackers where a simple automation, script, or small SaaS could help.”

This charter keeps you from chasing random demand you can’t actually act on.

Step 2: Know Where Demand Signals Hide

Demand signals show up anywhere people complain, ask for help, or talk about what they’re already paying for.

You don’t need a giant list. You need a few high-signal watering holes for the markets you care about.

Here are some of the best places for indie hackers:

Reddit

Look for:

• Role- or problem-based subs: r/Entrepreneur, r/SaaS, r/indiehackers, r/smallbusiness, r/freelance, r/marketing, r/devops, r/dataengineering, etc.
• Tool-specific subs: r/Notion, r/Hubspot, r/QuickBooks, r/Shopify, r/Stripe, etc. People complain about workflows, limitations, bugs, and pricing.
• Niche verticals: r/realestateinvesting, r/teachers, r/medschool, r/photography, etc.

Types of posts to watch:

• “How do you guys handle X?”
• “Is there a tool for Y?”
• “I’m losing my mind over Z.”
• “Rant: Why does [tool] still not do this…”

X (Twitter)

Use search and advanced filters:

• "is there a tool for", "how do you all manage", "what do you use for", "recommend a tool".
• Pains plus expletives: "this is so broken", "I hate doing", "wasting hours on", "manual" + [process].
• Follow segments: SaaS founders, creators, operators. Watch replies under their threads about processes, tools, and metrics.

Bookmark or save promising threads. Pay particular attention to posts with lots of replies or people chiming in “same”, “following”, “I hate this too”.

Forums, Communities, Support

• Niche forums: industry-specific communities (e.g., real estate, healthcare, manufacturing, agencies).
• Product communities: Notion, Airtable, Webflow, Figma, Shopify forums.
• Tool support forums and public issue trackers: people beg for features, describe workarounds, and share how broken their workflows are.
• Discord/Slack groups: look for recurring questions in #help, #support, or #questions channels.

You don’t have to be everywhere. Pick 2–4 places where your target audience hangs out and commit to observing them weekly.

Step 3: Learn To Spot Real Demand Signals (Good vs Weak)

Not every complaint is a good opportunity. You’re looking for repeatable, intense, and “money-adjacent” pain.

Here are patterns to watch.

Strong Demand Signals

1. Repeated complaints about the same workflow
   Example:
   • Multiple founders posting variations of:
     • “I’m copy-pasting Stripe data into Google Sheets every week to get basic revenue metrics.”
     • “Our MRR dashboard is always wrong; we manually fix churn and discounts.”

Why it’s strong: recurring problem, clearly tied to revenue, and people mention doing manual work.

2. Workaround hacks and ugly scripts
   Example:
   • “I wrote a quick Python script to export data from [tool] and merge it with [other tool]. It’s ugly but works for now.”
   • “We use Notion + Zapier + a custom Google Apps Script to track this because nothing else does what we need.”

Why it’s strong: if people are writing scripts, gluing tools, or hiring VAs, it’s painful enough to patch.

3. Explicit tool search and buying intent
   Example:
   • “Is there a tool that can automatically summarize our customer interviews?”
   • “What’s everyone using to track influencer outreach? I’ll happily pay for something that doesn’t suck.”
   • “Looking for a paid tool that [specific outcome].”

Why it’s strong: they are actively asking for a solution and often mention willingness to pay.

4. Complaints about existing tools’ limits
   Example:
   • “We use [popular tool], but once you have >10 clients, it becomes a mess.”
   • “Love Notion, but it completely breaks for recurring checklists across multiple clients.”

Why it’s strong: validated category (people are already buying), but specific segment is underserved.

Weak or Misleading Signals

1. One-off vents with no replies
   Example:
   • “Ugh doing my taxes sucks.” (0 replies, no follow-up.)

Why it’s weak: universal pain, but no signal about a specific workflow, no depth, no community engagement.

2. Generic startup complaints
   Example:
   • “Getting customers is so hard.”

Why it’s weak: true but too broad to turn into a clear product without more detail.

3. “Cool ideas” with no pain
   Example:
   • “Wouldn’t it be cool if there was an AI that automatically does X for you?” (No one replies “I’d pay for this” or shares their current workaround.)

Why it’s misleading: novelty-driven. You don’t see evidence of existing demand.

4. Ultra-niche, low-value problems
   Example:
   • “Wish there was an app that reminds me to water my single desk plant.”

Why it’s weak: the solution might be trivial, but not worth paying for or building around.

When doing demand discovery for indie hackers, the skill is not finding any complaint; it’s training your eye to recognize complaints that pair with money, workflow, and repeated behavior.

Step 4: Set Up A Simple Demand Log (Your Personal Opportunity Inbox)

Demand discovery only works if you log what you see. Otherwise everything just feels like noise and vibes again.

You don’t need a fancy system. A simple spreadsheet or Notion database is enough.

Create a table with columns like:

• ID – simple incremental ID or timestamp.
• Source – Reddit, X, forum name, Discord server.
• Link – URL to the post or thread.
• Audience – who has this problem? (e.g., “solo SaaS founders”, “HR at 20–200 employee companies”, “YouTube creators”.)
• Problem summary – short sentence in the user’s words.
• Workflow – what are they actually trying to accomplish? (Not just the tool they use.)
• Current workaround – manual steps, scripts, Excel, Notion, VAs, etc.
• Frequency – how often you see this (e.g., 1–5 scale).
• Intensity – how much pain/urgency you sense (e.g., 1–5 scale).
• Monetization potential – how close is this to revenue, time savings, or risk? (1–5.)
• Existing solutions – tools they mention using or that obviously exist.
• Your fit – how aligned this is with your skills/constraints (1–5).
• Notes – any quotes, context, or extra observations.

Keep entries short and rough. The goal is volume and consistency, not polished research reports.

Example Entry (Good Signal)

• Source: r/SaaS
• Link: [saved]
• Audience: Solo B2B SaaS founders
• Problem summary: “Manually cleaning and categorizing churn reasons every month from Stripe + Intercom.”
• Workflow: Export data → merge manually → categorize churn → update internal dashboard.
• Current workaround: Export CSVs, copy into Google Sheets, spend 2–3 hours monthly.
• Frequency: 4/5 (seen similar 6–7 times in 2 months)
• Intensity: 4/5 (words like “hate”, “waste”, “dreading it every month”)
• Monetization potential: 4/5 (directly tied to revenue optimization)
• Existing solutions: Some expensive analytics tools, but most solo founders not using them.
• Your fit: 5/5 (you’re comfortable with data/SaaS)
• Notes: Multiple comments: “following”, “same here”, “also doing this manually”.

Example Entry (Weak Signal)

• Source: X
• Audience: General knowledge workers
• Problem summary: “Meetings suck, wish they were shorter.”
• Frequency: 5/5 (everyone complains about this)
• Intensity: 3/5 (annoyance, not always action)
• Monetization potential: 2/5 (hard to tie to direct budget; crowded space)
• Your fit: 3/5
• Notes: Too broad, hundreds of existing tools; hard to wedge in.

Log both, but your scoring will separate them later.

Step 5: Run A Weekly Demand Discovery Routine

Demand discovery for indie hackers doesn’t need to be a full-time job. A simple weekly schedule works:

• 1–2 hours: scan your chosen channels.
• 30–60 minutes: log the best signals.
• 30 minutes: review and re-score top problems.

A simple weekly loop:

1. Collect
   • Search a few keywords on Reddit and X related to your target audience and processes: “invoice”, “onboarding”, “reporting”, “automation”, “spreadsheet”, “copy-paste”.
   • Sort by “Top” or “This month” to see recurring issues rather than fresh noise.
   • Open promising threads in new tabs and skim replies for “same”, “following”, “we do this too”.

2. Filter
   • Only log the strongest 10–20% of posts you see.
   • Ask: Is this a specific workflow with clear pain and some sign of repetition?

3. Log
   • Add to your demand log with quick scores for frequency, intensity, monetization potential, and your fit.

4. Review
   • Once per week, sort your log by total score and see if any problems are emerging as clear front-runners.
   • Update scores if you see the same problem again in a different context or community.

Over a month, this gives you dozens of signals and a ranked list of problems, instead of one or two hunches.

Step 6: Rank Problems With A Simple Scoring Model

You don’t need a PhD in decision science. A simple model keeps you honest.

One practical approach:

Score each problem from 1–5 on:

• Frequency – how often does this show up across channels?
• Intensity – how painful and emotional is it?
• Monetization – how close is this to revenue, cost savings, or compliance?
• Existing solutions gap – how underserved is this segment by current tools?
• Founder fit – how well does it match your skills, interest, and constraints?

Then compute:

• Total score = Frequency + Intensity + Monetization + Gap + Fit

Optionally, weight factors by multiplying:

• Weighted score = (Frequency * Intensity * Monetization) + Fit

Examples:

• A problem that’s frequent, intense, monetizable, and a good fit should float to the top.
• A problem that’s painful but totally outside your skill set gets penalized.

The point isn’t perfect math; it’s having a clear, repeatable way to compare problems so you don’t just chase the one that feels coolest that day.

Step 7: Decide Which Problems Deserve Experiments

After a few weeks, you should have a ranked list of problems.

Pick 1–3 of the highest-scoring ones and move them into lightweight experiments.

Filters when choosing:

• Can you reach people with this problem? (You’ve already seen them on Reddit/X/forums—good sign.)
• Can you build a credible prototype or service in 2–4 weeks?
• Is this close to money? (Revenue impact problems are easier to charge for.)

Avoid:

• Picking 10 problems and dabbling in all of them.
• Choosing something just because it’s “cool tech” if the demand signals are weak.

Step 8: Turn Problems Into Lean Experiments

For each chosen problem, design a tiny, fast experiment to test whether the demand holds up when you engage people directly.

Some options:

1. Problem-First Landing Page

• Headline: “Do you [pain] every [week/month] when you [workflow]?”
• Body: describe their current workaround in their words.
• CTA: “Get early access”, “Get a simple report every week”, “Join the pilot”.

Then:

• DM or reply to people from Reddit/X threads you found, referencing their post and the problem.
• Share the page in relevant communities (carefully and with value).

You’re testing: do people care enough to opt-in when the problem is front and center?

2. Manual or Concierge Service

Sometimes the fastest path is offering to do the job manually first.

Example:

• Problem: founders manually cleaning and categorizing churn every month.
• Offer: “I’ll clean, categorize, and report your churn reasons each month so you can focus on fixes.”

You’re testing: will people pay anything to avoid the pain right now?

If yes, you can later productize parts of the workflow.

3. Tiny Prototype Or Script

For highly technical markets, a basic tool can be the experiment.

• Build a simple script, Chrome extension, or Notion template that removes one painful step.
• Release it for free or cheap to people who complained.
• Watch: Do they actually install/use it? Do they ask for more?

You’re testing: do they care enough to integrate a new thing into their existing workflow?

Examples: Strong vs Weak Experiments From The Same Signal

Imagine you repeatedly see this on r/indiehackers and X:

“I always forget to follow up with people who showed interest in my product. I lose track of DMs and email replies.”

Two different experiment directions:

Weak Experiment

• Idea: “Build a full CRM for indie hackers.”
• Experiment: Spend 2 months building, then post on Product Hunt.

Issues:

• Too big; you skipped the problem-focused step and jumped to a generic solution.
• You didn’t test whether a small, focused fix would be enough (or better).

Strong Experiment

• Idea: “Simple follow-up queue for indie hackers that pulls in DMs and emails into one daily list.”
• Experiment:
  • Page that says: “Never forget to follow up with leads again. One daily list of who to ping next.”
  • Offer: tiny manual service or simple script for Gmail + generic DM export.
  • DM people from the threads who mentioned the problem, ask if they want into a small pilot.

More aligned with demand discovery for indie hackers: it’s tightly anchored to what people actually said, not your generic idea of a CRM.

Step 9: Keep Demand Discovery As An Ongoing Workflow

Even once you’re building something, keep your demand discovery loop alive:

• Block 1–2 hours each week just for scanning and logging new signals.
• Add a “tag” column in your log for whether the problem relates to your current product, adjacent opportunities, or something totally new.
• Capture weak signals: small pains that might grow into big ones over time.

This protects you from going heads-down for 6–12 months and emerging into a changed market.

Demand discovery isn’t a one-time ideation sprint; it’s an always-on radar.

Where Miner Fits In (And Why You Don’t Need It To Start)

Everything described so far can be done manually. A decent spreadsheet + discipline is enough to build a serious edge over vibe-driven idea picking.

The tradeoff: time and consistency.

Manually scanning Reddit, X, and forums takes effort, and it’s easy to miss weak signals or patterns across communities.

This is where a research product like Miner is useful:

• It continuously scans Reddit and X for you.
• It surfaces repeated pains, workaround hacks, and explicit buying intent instead of raw noise.
• It clusters and ranks problems by frequency, intensity, and opportunity.
• It tracks weak signals over time so you see when a niche complaint becomes a real wave.

Think of Miner as a daily demand brief that compresses what might take you hours into a few minutes each day. You still bring the constraints, judgment, and experiments; Miner feeds you higher-signal problems to consider.

The key point: you can run a lighter version of this workflow manually right now. If it becomes a bottleneck or you want broader coverage, you can plug in Miner to scale the discovery side without losing the problem-first mindset.

Putting It All Together This Weekend

If you want to implement this in a weekend:

1. Define your constraints
   • One page: skills, markets you care about, time, runway.

2. Set up your demand log
   • Spreadsheet or Notion with the fields above.

3. Choose 3–5 places to observe
   • A couple of subreddits, X searches, and one niche forum or community.

4. Do a 3–hour discovery sprint
   • Scan, filter, and log 20–40 of the strongest demand signals you can find.

5. Score and rank
   • Give each problem a quick 1–5 across frequency, intensity, monetization, gap, and fit.

6. Pick 1–3 problems
   • Choose the top ones that fit your constraints and excite you.

7. Design one tiny experiment per problem
   • Landing page, mini-service, or simple prototype.

You’ll end the weekend not with “a cool idea,” but with a ranked list of real problems and a concrete plan to test them.

That’s what demand discovery for indie hackers is really about: turning noisy conversations into a steady stream of evidence-backed opportunities, so you stop guessing and start building where demand already exists.