How to Test Your SaaS Idea Before Spending Money
Hassaan Malik
A scientist does not begin a risky experiment by constructing the largest possible machine. They look for a smaller test that can make the idea fail quickly and informatively. SaaS founders can do the same. Before paying for accounts, dashboards, automation, and infrastructure, they can test the promise hiding underneath: will a particular person take a meaningful step to make this problem smaller?
Write the riskiest belief as a sentence before choosing the test. Perhaps the buyer experiences the problem often, understands the promised outcome, will trust an external solution, or will pay enough to support delivery. A test that does not touch the risky belief can produce attractive but useless numbers. A page viewed by thousands says little about willingness to pay if the question was whether a finance manager would move sensitive work into a new tool.
A landing page is useful when the promise itself needs testing. Describe the audience, problem, outcome, and next step in plain language, then bring relevant people to it through direct outreach or a community where the problem already appears. The strongest button is not always “join a waitlist.” Booking a conversation, submitting a real example, requesting a pilot, or placing a refundable deposit asks for more commitment and therefore produces a stronger signal.
A concierge test removes software from the question entirely. Deliver the result manually for a handful of customers using forms, spreadsheets, existing tools, and human effort behind the scenes. This reveals the actual sequence, exceptions, and support burden while customers experience the intended value. The inefficiency is deliberate. It measures what should eventually be automated and whether the outcome remains valuable once someone must pay for it.
An explainer video or clickable prototype can test understanding when the workflow is difficult to describe. Show the important interaction without pretending the product exists, then ask the viewer to choose a concrete next step. These tests are weaker when they are polished into entertainment. Their purpose is not to collect applause for the design; it is to discover whether the buyer recognises the problem, understands the proposed change, and wants to continue.
Decide what result would change your behaviour before running the experiment. How many qualified people must agree to a trial? What commitment would justify a small build? What result would cause the audience or promise to change? The threshold need not be statistically grand, but it prevents a founder from reinterpreting every outcome as encouragement. Record who responded and why; a small result from the intended buyer can outweigh a large result from curious outsiders.
Testing before spending money does not mean refusing to invest until certainty appears. It means purchasing information in the least expensive form available. Conversations test the problem, landing pages test the promise, prototypes test comprehension, and concierge delivery tests the outcome. When one produces meaningful commitment, spend just enough to examine the next uncertainty. The result is not merely a cheaper start. It is a product whose first lines of code arrive carrying evidence about what they are for.