SaaS validation

How to Validate a SaaS Idea Before You Build It

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.

Six SaaS questions to answer before code

These are SaaS-specific decision questions, not six new validation methods. Choose the method separately based on the evidence you need.

Question 1

Recurring workflow

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.

Question 2

User and economic buyer

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.

Question 3

Current stack

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.

Question 4

Reachability and trigger

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.

Question 5

Design partner or pilot

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.

Question 6

Economic commitment

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.

Turn the SaaS question into a test

This page defines the SaaS-specific evidence job. Use the existing method and buyer-evidence guides for execution rather than repeating them here.

Where Stage 1 fits

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.

Run the free Stage 1 check