Validate a SaaS idea by testing the recurring workflow problem, separating the user from the economic buyer, understanding the current stack and switching friction, and asking for a commitment that costs the buyer something. Do that before you mistake positive feedback for demand.
Pre-build evidence can tell you whether a problem is recurring, whether the right buyer is reachable, whether the current workaround is painful enough to challenge, and whether someone will move toward a real decision. It cannot establish retention, churn, long-term adoption, support burden, reliability or scalable delivery before customers use a working product.
What recurring job or workflow breaks often enough that the buyer already spends time, money or risk dealing with it?
Evidence: Recent examples in the buyer's own words, plus the spreadsheet, manual process, incumbent software or workaround they already use.
Does not establish: A painful workflow does not prove the buyer will replace the current solution.
Who uses the workflow, who feels the pain, and who can approve or block the spend?
Evidence: A named user role, budget owner and decision path specific enough that you can find more comparable accounts.
Does not establish: User enthusiasm is not budget authority, and a buyer title alone does not prove urgency.
What tools, integrations and manual steps already hold the workflow together?
Evidence: The current software stack, hand-offs and switching costs, including data migration, security, procurement and internal change where relevant.
Does not establish: A weak incumbent does not prove the organisation will tolerate switching.
Can you repeatedly reach buyers when the problem is active rather than only through favours or your personal network?
Evidence: A repeatable channel plus a trigger that makes the workflow problem salient now: a new hire, failed process, compliance event, tool change, growth step or budget cycle.
Does not establish: Access to a buyer is not demand and does not establish acquisition economics.
Will a buyer help define success, provide access or data, involve the decision-maker and agree a dated next step?
Evidence: Observable effort from the buyer: scoping time, internal introductions, data access, security or procurement work, a scheduled decision or another costly action.
Does not establish: A free pilot can still stop before payment, and one design partner does not prove a repeatable market.
Will someone with budget put money or another meaningful consequence behind the problem?
Evidence: A paid pilot, deposit, signed order, formal procurement action or another commitment the buyer would notice if they walked away.
Does not establish: One commitment is evidence of demand, not proof of retention, expansion, renewal or lifetime value.
Choose the validation method: Use the cross-format method guide to compare seven evidence methods by what each can support and what each cannot establish.
Run stronger buyer interviews: Use questions that surface past behaviour, workarounds, consequences, buying roles and a real next action.
See where SaaS validation stops: Market evidence is only part of the commercial case; buyer, offer, funnel and commercial-decision work continue beyond this page.
GTM Right Stage 1 checks public evidence for the problem and current workaround. It does not prove buyer access, a pilot, willingness to pay, retention or SaaS economics.