Bespoke AI Software Needs a Price Test Before Code

The pattern repeats often enough to have a name. A specialist consultancy has a methodology that genuinely works, someone suggests productising it, and six months later they have bespoke AI software their clients admire but will not pay a recurring fee for. The software is real. The enthusiasm during demos is real. The subscriptions are not.

This is not a technology failure. The software usually does what it was built to do. It is a commercial assumption that went untested: that clients who value your expertise will also value self-service access to a software distillation of that expertise, and will pay monthly for the privilege. Those are two different propositions, and confusing them is an expensive habit.

Why does the assumption feel so reasonable?

Specialist consultancies often build their AI tools internally first, to make their own analysts faster or their outputs more consistent. The tool works. Clients see it in action and say things like “we’d love something like that.” This is encouraging, but that kind of enthusiasm is not a purchase signal. It is polite engagement. The gap between genuine admiration and willingness to pay a recurring fee, without your team attached, is wider than it looks from the inside.

Part of this is what you might call the expert’s curse in reverse. When you have spent years developing a methodology, you experience its value as self-evident. You know what bad looks like without the tool, and good looks like with it. Your prospective buyer, sitting in a thirty-minute demo, does not yet have that felt sense of the gap. They are being asked to commit to a monthly fee for a tool they have not yet needed at two in the morning when a deal is going sideways. That is a very different buying decision from retaining a consultancy whose expertise they already trust.

A piece in MIT Technology Review on repositioning retail for the AI era touches on a related structural problem: incumbents with deep domain knowledge often struggle with the distribution model that software requires. Specialist consultancies face exactly this transition, and the pricing question is where it becomes concrete.

What does a real price test look like?

The goal is not to ask people what they would pay. Direct willingness-to-pay questions produce unreliable answers because social pressure and hypothetical thinking both distort them. A respondent who tells you they would pay £500 a month is not lying, exactly. They are answering the question they think you want answered. The number means very little.

What you are trying to find instead is the point at which a potential buyer’s behaviour changes. That requires three stages.

The first is problem confirmation. Before any pricing conversation, establish that the buyer experiences the problem your software solves as a recurring cost, not an occasional inconvenience. A property surveying business might find that their clients care deeply about planning risk at the moment of acquisition but barely think about it thereafter. If the problem is episodic rather than continuous, a subscription is structurally wrong regardless of price point.

The second is value anchoring. What is the buyer currently spending to solve this problem, in time, in third-party fees, or in poor decisions made without good information? This sets the ceiling for what they can rationally pay. If the current cost is £2,000 a year in analyst time and occasional consultant fees, a £6,000 annual software subscription requires you to be selling something transformative, not merely convenient.

The third is simulated commitment, and this is the stage many consultancies skip. Showing someone a prototype and asking whether they would pay for it is still hypothetical. A better test is asking for something with skin in it: a letter of intent, a refundable deposit against a beta access fee, or agreement to a paid pilot at a rate that would need to be commercially viable at scale. The number of people who say yes at this stage, compared with those who showed enthusiasm in the demo, is your real conversion signal. The drop-off is almost always instructive and sometimes brutal.

Is recurring revenue the right model at all?

Even if buyers will pay something, the harder question is whether they will pay on a schedule. Professional services clients are accustomed to project fees. They have procurement processes built around statements of work. A subscription is a different kind of relationship: it requires the buyer to actively choose not to cancel every renewal period, which means the software has to keep earning its place.

This is not an argument against building. It is an argument for being specific about what you are actually selling. Some bespoke AI software fits naturally into a usage-based model rather than a flat monthly fee, which can be easier to justify because the cost scales with the value realised. Others are genuinely project-scoped: a one-time AI-assisted analysis priced accordingly, rather than forced into a SaaS shape because SaaS commands better multiples on paper.

The businesses that get this right tend to have run their methodology as a paid service long enough to understand which parts of the engagement clients value most and would pay to access independently. They are not guessing at product-market fit. They have years of client feedback telling them where the leverage actually is. The software then distils those specific high-value moments rather than trying to replicate the whole service.

What to do before you commission a line of code

Run the three-stage test above with enough potential buyers to see genuine patterns, not just outliers. Look for variance, not just averages. Two clients who would pay £1,000 a month and six who would pay nothing tells you something different from eight clients who would each pay £250. Talk to the people who say no, particularly the ones who seemed enthusiastic until you asked for a commitment. Their objections are your product brief.

If your methodology already works as a delivered service and the price test suggests real recurring demand, the next question is how to build efficiently without taking on all the technical risk yourself. That is exactly what our SaaS Product Build partnership is designed for: we co-build the software with you and share the upside, which means our incentives are aligned with yours from day one, not just during the invoice cycle.