Login, reports, collaboration and monthly billing are software components. They do not establish a SaaS business. Before commissioning development, test whether a recurring problem, a recognisable buyer and a workable delivery model exist.
SaaS product validation makes the assumptions visible. Software can support a repeatable process, but it cannot turn a weak assumption into evidence simply by making the workflow look polished.
1. Identify the problem and the buyer
Describe the problem without naming your solution. “Team leaders assemble records from several systems every week and notice exceptions too late” is more testable than “companies need an AI dashboard”.
Separate the user, influencer, decision-maker and payer. Who experiences the problem, pays for the workaround, approves change or can block adoption? Choose an initial situation with similar language and work practices; “small businesses” alone is too broad to test precisely.
2. Observe the current alternative
The competitor may be a spreadsheet, email, WhatsApp, manual work, a service provider or doing nothing. Follow the process from its trigger to its outcome. Record people, information, copying, waiting, corrections and recurring exceptions.
Behaviour provides stronger evidence than an attractive feature description. A rare inconvenience may not justify change. A workable manual method may be adequate, or the organisation may lack the data necessary for automation.
3. Test willingness to commit and pay
Interest is not a buying decision. Ask whether a specific buyer will make time for a pilot, provide realistic data, reserve budget or enter a defined paid engagement. Establish what result would justify that commitment.
You do not need the perfect final price before building. You do need a plausible exchange that works for both parties. Extensive personal setup and support cannot be costed as if delivery were entirely self-service.
4. Check whether the workflow repeats across customers
Describe roles, permissions, records, approvals and exceptions. Decide where each record officially belongs and who may correct it when systems disagree.
Early custom work can teach you about the process. Identify which variations can become configuration and which change the core workflow. If every customer needs a different process, the proposed subscription product may actually be a series of custom projects.
5. Define the smallest saleable first version
A first version needs one audience, one important problem and a complete path from input to useful result. Include enough access control, onboarding, support and fallback to use it responsibly. Define a success criterion before the pilot.
Remove features that demonstrate possible futures but do not complete that value exchange. A complex subscription system or management dashboard may be unnecessary while a controlled internal procedure supports the first customers.
6. Assign operational ownership
Who handles questions, incidents, onboarding, external-system changes, corrections, account access, monitoring and recovery? Missing explanations become support requests; weak imports become manual cleanup. Include those responsibilities in the business model.
Differentiate support the product can eliminate from support that remains human. A low subscription price can become impractical if each customer needs substantial personal attention.
7. Map privacy, security and a go/no-go decision
List the data processed, its purpose, permitted users, external recipients and sensitive or irreversible actions. Define access revocation, bounded event records and incident handling from the start.
Proceed when the problem recurs, a buyer actively commits, the workaround is understood, the workflow repeats and necessary data, support and risk controls are feasible.
Stop or reframe when the need is theoretical, every customer changes the core process, nobody owns the input or outcome, adoption requirements are unrealistic or too many unproven dependencies must succeed together.
Separate product evidence from technical evidence
A customer pilot asks whether people choose to use and pay for the workflow. A technical experiment asks whether roles, records and exceptions can be handled. A working demo proves neither a profitable operation nor willingness to pay.
Read about custom software development, web app development and how we work. Once the assumptions are explicit, compare the factors in online platform development costs.