Most indie hackers and lean teams don't have a demand problem; they have a signal problem.

You scroll Reddit and X, see pain everywhere, bookmark a few threads, maybe jot a note… and then it all vanishes into the void. No continuity. No compounding insight. No clear call on what to build next.

A demand research system for indie hackers solves that: a simple, reusable loop that keeps capturing and ranking real demand while you focus on shipping.

This article shows you how to set that up with basic tools and a workflow you can actually maintain.

What A Demand Research System Is (And What It Is Not)

A demand research system is:

• A repeatable loop for turning messy conversations into structured demand signals.
• A lightweight way to log, score, and revisit opportunities over time.
• A companion to your build cycle, not a separate “research phase.”

It is not:

• An endless “idea board” you never prune.
• A full-time research job that delays shipping.
• A one-off sprint you abandon after a week.

The goal: when you ask “What should I build or prioritize next?”, you don’t guess. You open your system and use the best available signals.

The Core Loop: Capture → Log → Score → Review

Think in terms of a small, durable loop:

1. Capture: Save interesting pain points and buyer intent moments from Reddit/X and elsewhere.
2. Log: Normalize them into a consistent format in a spreadsheet or database.
3. Score: Quickly rate each one on a few simple criteria.
4. Review: On a cadence, sort by score, prune, and decide what to explore or ship.

If you keep those four steps extremely cheap in time and friction, the system keeps running in the background while you build.

Step 1: Define What Counts As A “Demand Signal”

Before tools, decide what you’re actually looking for. Otherwise, you’ll drown in “interesting” but low-value posts.

For indie hackers and lean teams, focus on:

• Clear pain: “I spend 3 hours every week doing X manually.”
• Repetition: The same complaint or workaround showing up across threads.
• Buyer intent: “Happy to pay for something that does X”, “Is there a tool for…?”
• Non-consumption: People stuck in spreadsheets, copy-paste, or scripting to get something done.

Create a quick checklist you keep in your notes:

• Is there an explicit pain or frustration?
• Can I describe the workflow in one sentence?
• Would I be surprised if nobody paid to fix this?
• Have I seen this more than once?

If you can’t answer “yes” to at least two of those, don’t log it. This keeps the system lean.

Step 2: Set Up A Minimal Product Opportunity Log

You don’t need a fancy CRM. A single spreadsheet or table is enough to start.

Use something like Google Sheets, Notion, Airtable, or even a markdown table in Obsidian. Whatever you already use daily.

Suggested columns for your product opportunity log:

• ID – Short unique id (e.g., R-2024-04-01-1).
• Problem summary – One sentence: “PMs manually stitch user feedback into a launch brief.”
• User segment – Who is complaining? “Indie SaaS founders”, “Shopify store owners”.
• Workflow step – Where in their workflow does this hurt? “Reporting”, “handoff”, “billing”.
• Source – Reddit, X, Slack, customer call, etc.
• Source link – Direct link or note reference.
• Evidence count – How many distinct mentions you’ve seen.
• DIY / workaround – What they do today (scripts, Notion, spreadsheets, Zapier).
• Buyer intent signals – Any “I’d pay for this” language.
• Impact score – 1–5 (how costly/urgent it seems).
• Fit score – 1–5 (how well it fits your skills/strategy).
• Stage – Backlog, Investigating, In discovery, Building, Shipped, Dropped.
• Notes – Quick context.

This is your single source of truth. If it’s not in the log, it doesn’t exist.

Step 3: Make Capture Frictionless (Reddit, X, Everywhere)

You don’t want to stop what you’re doing and “do research” all day. Instead, capture as you go, in seconds.

Quick capture workflow

Pick one capture method and stick with it:

• A mobile note app with a single “Demand Inbox” note.
• A “Demand” bookmark folder in your browser.
• A Telegram/Discord channel where you DM yourself links plus a one-liner.
• A simple inbox table in Notion.

Every time you see a promising post:

1. Save the link.
2. Add a 1–2 sentence summary of the pain and who has it.
3. Tag with a rough segment if you can.

Example capture note:

“Indie devs on r/selfhosted complaining about maintaining 10+ homelab containers; want simpler updates + monitoring. Link: [URL]”

That’s enough for now. The goal: <30 seconds per capture.

Using Miner as a pre-filter (optional)

If you subscribe to Miner, treat it as a pre-filtered stream:

• Use Miner’s brief to surface mentions with clear pain and buyer intent across Reddit/X.
• Add only the highest-signal items into your demand inbox, not everything from the brief.
• When you notice patterns (same complaint across different communities), log one “opportunity” and bump its Evidence count.

Miner replaces some of the manual hunting; your system is still where you turn those signals into structured opportunities.

Step 4: Move From Inbox To Log (Once Or Twice A Week)

Don’t log in real time. Batch it.

Pick a fixed time block once or twice a week:

• e.g., Tuesday and Friday, 25 minutes each.
• Calendar-block it as “Demand Log”.

During that block:

1. Open your demand inbox (notes/bookmarks/Miner brief).
2. For each item, decide: log or discard.
3. If logging, fill in the opportunity log fields:
   • Clean problem summary.
   • User segment.
   • Source and link.
   • Evidence count (start at 1).
   • Quick ratings for Impact score and Fit score.

If an opportunity already exists:

• Increment Evidence count.
• Update Notes with the new angle/link.
• Adjust scores if the new evidence is stronger or weaker.

Aim to process everything in your inbox. This is where “interesting noise” becomes a structured asset.

Step 5: A Simple Scoring Model You’ll Actually Use

Overcomplicated scoring kills systems. Use something you can do in 10 seconds.

Here’s a practical model:

• Impact score (1–5)
  • 1 – Minor annoyance, low time/$$ loss.
  • 3 – Moderate frustration, repeated work, visible cost.
  • 5 – Critical, blocks progress, clearly affects revenue or time in hours/week.

• Evidence count (integer, but you can convert to a 1–5 band)
  • 1 – Single clear signal.
  • 2–3 – Multiple independent mentions.
  • 4+ – Recurring pattern across different threads/communities.

• Fit score (1–5)
  • 1 – Far from your skills, interests, or network.
  • 3 – You can build it, but it’s a stretch.
  • 5 – Perfect fit: you understand the workflow deeply or already have users there.

Then define a simple formula:

Total score = (Impact score * 2) + Evidence band + Fit score

Where Evidence band is:

• 1–2 mentions → 1
• 3–5 mentions → 3
• 6+ mentions → 5

You want scoring to be approximate, not precise. The goal is to rank, not predict the future.

Step 6: Weekly Review: Turn Signals Into Decisions

The review is where this becomes a demand research system, not an idea graveyard.

Once a week, 30–45 minutes:

1. Open your log and sort by Total score (or by Impact score then Evidence count).
2. Look at the top 5–10 opportunities.
3. For each, decide:

• Investigate: Talk to 3–5 people, validate edges, see if money moves.
  • Watch: Keep logging evidence but don’t act yet.
  • Drop: Clearly not worth your time; mark Dropped to reduce clutter.

4. Update Stage accordingly.
5. Assign one or two to your upcoming product cycle:
   • Run interviews.
   • Build a small tool/automation.
   • Ship a test feature or micro-SaaS.

Patterns matter more than individual posts. If the same workflow keeps resurfacing, that’s a strong candidate to pursue.

Example 1: Manual Reporting Hell → SaaS

Imagine you keep seeing posts like this on r/SaaS and Twitter:

• “Every month I manually export Stripe, pull numbers into Google Sheets, and update a Notion dashboard.”
• “Why is there no simple way to send monthly MRR and churn emails to investors?”

Your process might look like:

1. Capture:
   • Save 3 different posts complaining about monthly metrics reporting.
2. Log:
   • Problem summary: “Founders manually compile monthly metrics into investor updates.”
   • User segment: “Indie SaaS founders, early-stage startups.”
   • Workflow step: “Reporting / investor updates.”
   • Evidence count: 3.
   • Impact score: 4 (recurring monthly pain, involves error-prone manual work).
   • Fit score: 4 (you’re comfortable with APIs and finance-ish tools).
3. Score:
   • Evidence band: 3 (3–5 mentions).
   • Total score = (4 * 2) + 3 + 4 = 15.
4. Review:
   • Top of your list this week.
   • Decide to Investigate:
     • DM 5 founders who complained; ask how they do reporting now.
     • Test whether they’d pay $20–$40/mo for a dead-simple reporting tool.
5. Build:
   • Scope a tiny MVP: connect Stripe + a template email with metrics.
   • Use your log to track feedback and new evidence as you ship.

The system didn’t “give you” the idea. It constantly surfaced and prioritized it until it was too obvious to ignore.

Example 2: Recurring Workflow Frustration → Niche Tool

You’re active in devops-adjacent spaces and notice a theme:

• Reddit threads about engineers forgetting to rotate API keys on side projects.
• Tweets about surprise downtime due to expired sandbox credentials.
• People sharing custom scripts to check for expired tokens in CI.

Run it through your system:

1. Capture:
   • DM yourself 4 links with short summaries.
2. Log:
   • Problem summary: “Engineers forget to rotate/test API keys/secrets on side projects; discover breakages late.”
   • User segment: “Indie devs, small teams with many small services.”
   • Workflow step: “Maintenance / reliability.”
   • DIY / workaround: “Cron scripts, custom CI steps, sticky notes.”
   • Evidence count: 4.
   • Impact score: 3 (events are painful but not constant).
   • Fit score: 5 (your background is in devops/security).
3. Score:
   • Evidence band: 3.
   • Total score = (3 * 2) + 3 + 5 = 14.
4. Review:
   • High score but maybe niche.
   • Mark as Investigating: run a short survey or talk to devops friends.
   • If interest is real, test a tiny “token expiry monitor” service.

Again, the system keeps the idea alive, compounding evidence instead of letting it disappear into bookmarks.

Integrating Reddit and X Without Drowning In Noise

To keep Reddit/X from eating your entire day:

• Pick 2–3 core communities:
  • Where your target user already hangs out.
  • Where real work and tools are discussed, not just memes.
• Create saved searches:
  • On Reddit: site:reddit.com "how do you keep track of", "manual process", "tool for", "is there a way to automate".
  • On X: Follow a few practitioners who complain loudly about tools and workflows.
• Limit active scanning:
  • 15–20 minutes per weekday, max.
  • During that time, you’re not debating or posting, just observing and capturing.

If you use Miner, you can:

• Treat the daily brief as your “saved search on steroids”:
  • It already filters for pain and buyer intent.
• Spend your 15–20 minutes reviewing those high-signal snippets instead of raw feeds.
• Capture only the strongest items into your inbox/log.

The system is the same; you’re just feeding it cleaner inputs.

Keeping The System Running While You Ship

The main failure mode: you start enthusiastically, then abandon the system when building gets intense.

To avoid that, make the system intentionally small:

• Time-box capture:
  • Max 20 minutes/day on Reddit/X/Miner briefs.
• Time-box logging:
  • 2 sessions/week, 25 minutes each.
• Fixed weekly review:
  • 30–45 minutes, same time every week.

Use triggers:

• Right after your weekly standup or solo planning session, do the review.
• Tie your “Demand Log” blocks to actions you already take:
  • e.g., after your Friday retro, before you close the laptop.

Guardrails:

• If you skip a week, don’t “catch up” with a massive session.
• Instead, prune your inbox quickly; log only the clearest opportunities.
• The goal is continuity, not completeness.

Using The System To Choose And Refine Product Ideas

When it’s time to make a call on what to build next, use your log to drive the conversation:

1. Filter:
   • Stage = Backlog or Investigating.
   • Sort by Total score, then by Evidence count.
2. Shortlist:
   • Take the top 5–10 for your current skillset/strategy.
3. Reality check:
   • For each, ask:
     • Do I know 5–10 people I can talk to about this?
     • Can I build a meaningful test in 2–4 weeks?
     • Is this aligned with where I want my product/brand to go?
4. Choose:
   • Pick 1–2 to actively explore this cycle.
   • Move them to In discovery or Building and add concrete next steps.
5. Refine:
   • As you talk to users and ship small pieces:
     • Update Notes, Evidence count, and Impact score.
     • Split opportunities if needed (“reporting tool” might become “Stripe-only investor updates” vs “multi-source founder dashboard”).

Over time, your product opportunity log becomes a compounding asset. Even if you kill an idea, the insight stays, and you’ll recognize it if it resurfaces differently.

Tooling Stack: Simple, Not Fragile

You can build this with tools you already use daily. For example:

• Capture:
  • Apple Notes / Google Keep / Obsidian note named Demand Inbox.
  • Or a private Telegram channel where you forward links.
• Log:
  • Google Sheets: easy sorting, sharing, basic filters.
  • Or Notion/Airtable if you prefer databases.
• Light automation (optional, later):
  • Zapier/Make: save bookmarked tweets/Reddit posts into your inbox automatically.
  • Miner: daily brief of high-signal Reddit/X posts into your email or a Slack channel.

Don’t start with automation. Start manually, refine your schema and workflow, then automate the boring edges once the system feels stable.

Putting It All Together (Today)

You can set up the core of this demand research system for indie hackers in a single afternoon:

1. Create your Demand Inbox (note or channel).
2. Create your Product opportunity log (spreadsheet/table using the schema above).
3. Add two calendar blocks/week for logging and one for review.
4. Pick 2–3 communities and a small set of saved searches.
5. For the next 7 days:
   • Capture signals casually as you browse.
   • Log and score them during your time-boxed sessions.
   • Run your first weekly review and pick one opportunity to investigate.

If you already use Miner, plug its daily brief into step 5 as a curated stream of pain and buyer intent; your system will become more signal-dense with less manual scanning.

The key shift is this: stop treating research as a one-off “what should I build?” crisis, and start treating it as a small system that runs alongside your product cycle.

Once that system is in place, you’re not guessing anymore. You’re choosing from a living, ranked map of real demand.