Portfolio & product spotlights
How Vervelio built NidaMind: turning public complaints into validated product ideas
Short answer
Vervelio built NidaMind as a pipeline that collects public complaints from Reddit, Hacker News, Stack Overflow, GitHub Issues and app-store and G2 reviews, embeds each one and clusters similar complaints in Postgres with pgvector. On every scheduled run it scores each idea on willingness to pay, urgency, frequency, competition gap and trend velocity, and marks an idea validated only at a score of 6.0 or higher with at least 10 complaints from 2 or more sources.
Public user complaints expose genuine operational friction, yet building software directly from unverified feedback introduces significant development waste. Traditional discovery approaches often poll passive enthusiasm rather than active operational pain. Teams can systematic dismantle this risk by converting unstructured complaints into formal specifications, and checking problem recurrence across competing products.
Translating public user complaints into software requirements specifications#
Software teams extract actionable requirements and edge cases from public forums by deploying Crowd-based Requirements Engineering (CrowdRE) (arxiv.org). CrowdRE leverages publicly available feedback from forums and app store reviews to indirectly capture user needs without direct, resource-intensive user interviews.
- Public user complaints
- CrowdRE forum mining
- LLM heuristic filtering
- Edge case extraction
- Formal requirements
Extracting non-functional requirements (such as usability constraints) requires systematic filtering of raw text. A precursor study on prompt engineering demonstrated that large language models (TLLM) can filter usability-relevant reviews using an initial prompt developed through two engineering iterations and coding guidelines derived from the 10 Nielsen Usability Heuristics (arxiv.org). Non-functional requirements define system qualities and operational constraints rather than specific functional behaviors. Researchers found that tailored prompts tend to make LLMs slightly more permissive, gathering a limited amount of irrelevant reviews rather than omitting critical user feedback. In Scott Shinn's experience as Founder, Vervelio, AI Systems Architect, allowing slight permissiveness ensures subtle edge cases reach the engineering specification stage.
Once relevant feedback is gathered, AI agents assist product managers by simulating scenarios, summarizing feedback examples across diverse user cohorts, and surfacing edge cases (productschool.com). This process transforms unstructured public gripes into structured, testable specifications before architectural commitments occur.
Validating market demand and willingness-to-pay before engineering#
Customer discovery and customer validation serve two distinct functions during product evaluation. Customer discovery focuses on understanding the problem through conversation and observation to determine what to build, whereas customer validation concentrates on getting a smaller group to commit with real behavior (such as pre-orders, deposits, or paid pilots) to confirm whether anyone will pay (growthmentor.com).
Commercial Viability = Real Behavioral Commitment > Stated Verbal Interest
To evaluate market demand through quantitative consumer surveys, rework guidelines indicate that teams need at least 200 to 300 responses to achieve statistically meaningful results (resources.rework.com). When assessing survey responses, a product faces a clear demand problem if less than 40% of respondents state they would definitely or probably buy at the target price.
| Validation Method | Core Mechanism | Primary Metric or Threshold | Role in Evaluation |
|---|---|---|---|
| Consumer Surveys | Structured price and problem questionnaires | At least 200 to 300 responses (resources.rework.com); ≥40% purchase intent | Evaluates market demand and target pricing |
| Discovery Interviews | Non-pitch conversation and observation (growthmentor.com) | Qualitative identification of root problems | Clarifies what problem to solve |
| Early Usability Tests & Betas | Direct task observation in small beta programs (productschool.com) | Real context, task friction, and edge cases | Watches user actions instead of verbal opinions |
| Validation Commitments | Behavioral proof of payment (growthmentor.com) | Pre-orders, deposits, or paid pilots | Proves willingness-to-pay before building |
Software development teams bridge the gap between reported problems and functional execution by observing user friction directly. Small beta programs run on early builds enable product teams to observe real usage, real context, and real edge cases in the wild rather than relying on opinions (productschool.com).
Evaluating complaint patterns and criteria for product viability#
Distinguishing an isolated user grievance from an addressable market gap requires category-level aggregation.
Evaluating market viability requires auditing whether a recurring issue justifies an independent product:
- Confirm that the problem is not an intentional, scope-limiting design choice by a single vendor (bigideasdb.com).
- Identify whether the functional gap appears across twenty different products in the same software vertical.
- Track whether users in public discussions describe building manual, multi-step workarounds to bypass the limitation.
Vervelio applies this evaluation protocol across its venture-studio pipeline: enforcing day-one governance, cost controls, and operational guardrails before deployment. Practitioners assessing public complaints this week should audit their target backlog against cross-product recurrence thresholds, conduct discovery to isolate the manual workaround, and secure written pilot agreements before writing production code.
| Dimension | Customer Discovery | Market Validation |
|---|---|---|
| Primary Goal | Understand the user's real problem, coping mechanisms, and what to build | Prove whether prospective users will pay before engineering begins |
| Core Method | Non-pitch interviews, open conversation, and task observation | Securing behavioral proof and commitments |
| User Commitment Type | Time and verbal descriptions of operational context | Pre-orders, deposits, or paid pilots |
| Decision Output | Clarified operational requirements and functional direction | Go/no-go commercial decision based on payment behavior |
| Signal or Observation | Operational Interpretation | Prescribed Action |
|---|---|---|
| Feature missing from a single product | Likely a deliberate, scope-limiting design choice by one vendor | Hold engineering; monitor competing software tools for pattern emergence |
| Same functional gap recurring across 20 products | Identifies an aggregated, commercially viable market gap | Initiate discovery interviews and define manual workarounds |
| Survey purchase intent below 40% at target price | Fails market validation threshold; indicates a severe demand problem | Kill or pivot the product concept prior to writing production code |
| LLM review filter captures irrelevant feedback | Expected model permissiveness to avoid dropping critical edge cases | Retain heuristic prompt; allow slight permissiveness to preserve edge cases |
| Survey sample size under 200 to 300 responses | Statistically underpowered sample for consumer demand evaluation | Expand survey distribution channels to reach at least 200 to 300 responses |
Pre-Engineering Validation ROI Calculator
Calculates the expected cost savings and return on investment from upfront demand and willingness-to-pay validation before committing software engineering resources.
Pre-Engineering Validation Spend:
Total Engineering Exposure at Risk:
Net Expected Waste Avoided:
Validation ROI:
Frequently Asked Questions
What data thresholds indicate a public complaint represents a viable SaaS product?
A gap represents a viable SaaS market when the identical missing feature or complaint recurs across at least twenty competing products, rather than appearing as an isolated absence in a single product where it might reflect an intentional design choice. Quantitatively. Market demand requires validation through consumer surveys reaching 200 to 300 responses, with at least 40% of respondents confirming they would definitely or probably purchase at the target price point.
When should a validated complaint-driven concept be killed rather than built?
A concept should be killed or flagged as having a demand problem if fewer than 40% of respondents in a statistically meaningful consumer survey (200 to 300 responses) state they would definitely or probably buy the product at the target price, or if prospective users refuse to commit to behavioral validation such as pre-orders, cash deposits, or paid pilots.
Sources
- [PDF] User Reviews as a Source for Usability Requirements - arXiv - arxiv.org
- Product Manager Playbook for Customer Feedback - productschool.com
- Market Validation & Customer Discovery (2026 Guide) - GrowthMentor - growthmentor.com
- Best Tools to Find SaaS Ideas From Reviews & Complaints (2026) - bigideasdb.com
- "Product Research & Validation: Market Discovery Before Launch" - resources.rework.com
- Vervelio (first-party AI-visibility tracking) - Vervelio (first-party AI-visibility tracking) (2026-09-17)