Validate a SaaS Idea from an Existing Service

To validate a SaaS idea from an existing service, price it like a product before you build anything. If your current clients will pay a subscription rate for a defined scope of your method, you have demand. If they will not, you have saved yourself a costly and demoralising build.

Technical and regulated businesses that consider productising their services eventually have the same conversation: "We could automate a lot of what we do. Should we build something?" The answer they need is not about technology. It is about whether anyone will pay for the automated version at a price that makes the economics work. That question has a test, and you can run it without writing a line of code.

Why does willingness to pay reveal more than a user interview?

There is a meaningful distance between "this sounds useful" and "I will pay £X per month for this." User interviews, discovery workshops, and expressions of interest are not worthless, but they cannot carry the weight that many technical founders place on them. People are polite. They say yes to hypothetical products in the same spirit that they agree to things they will never use. Actual price acceptance is different. When a client signs a contract at a fixed fee for a defined output, they are committing something real.

This is especially true in consultancy and regulated services, where your clients already trust your judgement and already pay for your time. The question you are testing is not whether they value your expertise. They demonstrably do. The question is whether they will pay for your output when it arrives at a fixed cadence, in a fixed format, without a bespoke engagement. That is a genuinely different proposition, and a pricing response is the only honest answer to it.

This is what proof of demand validation means in practice: not a survey, not a waitlist, not a letter of intent, but actual price acceptance or rejection from people who know exactly what they are buying. The clients who know your work best are the hardest to fool and the most valuable signal you have.

What does a consultancy to SaaS pricing experiment actually involve?

It does not require a product. It requires a proposal. Structure your next retainer renewal, or your next project offer, as if you were selling software: a named, bounded scope (not "we will advise you on X" but "you receive Y report and Z data summary, delivered monthly"), a fixed monthly fee, and a defined term. Then watch the response.

Three responses matter. Clients who accept without negotiation are telling you the value is clear and the price is right. Clients who accept with price negotiation are telling you the value is real but the calibration needs work. Clients who decline because they want the bespoke relationship are telling you this segment is not your SaaS market, at least not yet. All three responses are useful. The only response that should worry you is silence, which usually means the scope was unclear.

You do not need a large sample. You need a readable pattern. Six to twelve clients, observed across one or two renewal cycles, will tell you more than any market sizing report. The goal is not statistical significance. It is a commercial signal strong enough to justify the investment of building.

The discipline of defining a fixed scope is itself valuable, separate from what your clients tell you. Many technical businesses discover, when they try to write a product proposal, that their method contains three or four genuinely repeatable components and one bespoke judgement layer that varies by client. That is useful information for product design. The repeatable components become the SaaS. The judgement layer may remain a service, or it may become the onboarding, configuration and support model that sits around the product. Either way, you arrive at a product architecture before you have a product, and that clarity is hard to reach any other way.

Is proof of demand validation different from running a pilot?

Yes, and the difference matters more than many technical founders acknowledge. A pilot or proof of concept tests whether a thing can be built, or whether a method produces a useful result. Proof of demand validation tests whether clients will pay for it at a price that makes the business work. Technical organisations reach for the proof of concept first, quite naturally, because it plays to their strengths. But a technically successful pilot that was never going to convert to recurring revenue is just an expensive service engagement with a misleading name.

MIT Technology Review's coverage of debates around AI reasoning capability is a useful illustration here. Demonstrating a capability is not the same as having a product that people will pay for. The same logic applies to your inspection workflow, your accreditation process, or your modelling method. You may have something technically impressive. The pricing experiment tells you whether it is commercially compelling.

There is a version of the consultancy to SaaS pricing conversation that skips this step and goes straight to architecture and build. It is tempting, especially when you have a clear technical vision. The businesses that have had the smoothest product launches are the ones who arrived with a pricing signal already in hand. The conversation about what to build, and at what price point, is far more productive when it is anchored in actual client behaviour rather than assumption.

What if the experiment produces a weak or mixed signal?

That is also useful information, and it is far better to have it before you build. A weak signal usually means one of three things: the scope is not yet defined clearly enough for clients to buy it confidently, the price point is misaligned with the value they perceive, or the right buyer is not the client you are currently serving. Each of these has a fix that does not require writing software.

A mixed signal, where some clients accept and others decline for coherent reasons, often points to segmentation. You may have two or three distinct client types with different needs. The SaaS opportunity may exist for one of them but not the others. That is a product strategy insight, and it is far easier to act on before you have committed to a particular build than after. Pre-selling software, even in this informal sense, forces the segmentation question earlier than it would otherwise arise.

If you run the experiment twice, with a refined scope and price each time, and the signal remains weak, you have still learned something valuable. Either the method is not yet product-shaped, or the client base you have does not map to the market you would need. Neither conclusion is permanent, but both are far cheaper to reach through a pricing experiment than through a full build.

If your experiment produces a positive signal, the next step is building the product. That is where our SaaS Product Build partnership begins: we co-build the software with you and share the commercial upside, so our incentives stay aligned with yours throughout. When you arrive with pricing data from real clients, the first conversation is about architecture and go-to-market, not whether there is a market at all.