How To Price Bespoke AI Software

A specialist consultancy, usually five to fifty people, has identified something genuinely clever: a repeatable analytical process, a proprietary scoring method, a way of synthesising industry data that clients are willing to pay for. Someone has had the sensible idea of wrapping it in software. It is a good ambition. The maths, almost without exception, has not been done.

What does your day rate actually tell you about professional services AI pricing?

A consulting day rate is a cost-plus number with a margin. It reflects your salary expectations, your overhead, your utilisation target, and whatever premium your reputation commands. It tells you almost nothing useful about what a software product based on your method should cost, because software pricing is not cost-plus. It is value-minus: you start from what the outcome is worth to the buyer, then work backwards to a price they will pay on a subscription, then work backwards again to ask whether you can build and maintain the thing at a cost that leaves a viable margin.

Here is a simplified version of the test we walk people through. Take a client who currently buys, say, fifteen days of your time a year at £1,800 a day. That is £27,000 annually. Now ask: what portion of that work could a well-built AI tool actually replace or accelerate? Be honest. If the answer is roughly a third, the value being delivered by software is around £9,000 per year per client. A subscription product might capture somewhere between fifteen and thirty per cent of the value it delivers, so your realistic annual contract value per customer sits somewhere between £1,350 and £2,700. Multiply that by the number of clients you could realistically sell to in year two and you have a revenue ceiling to test against your build cost.

Most practices run this calculation and discover one of two things. Either the numbers actually work and they have been leaving money on the table by not building. Or the numbers do not work, and the honest conclusion is that the value of what they do is inseparable from their personal judgement, which software cannot replicate at a price clients will pay. Both conclusions are useful.

Why does consulting logic corrupt a SaaS pricing model for professional services?

Consulting businesses are trained to think in project budgets, not unit economics. When a partner at a specialist practice thinks about what the software should cost, they tend to anchor on one of two numbers: what it costs to build (which leads to a one-off licence fee that funds nothing ongoing), or what a single client currently pays (which leads to enterprise pricing that makes it impossible to scale down-market). Neither is a product business. One is a bespoke project with a software deliverable. The other is consulting with a dashboard bolted on.

A recent piece in MIT Technology Review on AI's impact on retail touched on this dynamic obliquely: the businesses that benefit most from AI are not those that automate what they already do, but those that redesign what they sell around what AI makes possible. That reframe applies with equal force to professional services. The question is not "how do we charge for our AI tool" but "what new thing does this tool allow us to sell that we could not sell before." Often that is access to the methodology at a lower price point than a day rate, which means reaching clients who could never afford you as a consultant. That is a genuine product opportunity. It requires building for a different buyer, not just wrapping your existing service in an interface.

What does a viable recurring revenue model actually look like?

The practices we have seen make this work share a few characteristics. They are selling to a defined professional audience with a recurring operational need, not a one-off strategic question. The output of the tool is something the buyer uses monthly or weekly, not once. And the methodology is genuinely differentiated: it produces an answer a generalist AI assistant cannot produce from a blank prompt, because it encodes proprietary data, industry-specific logic, or a calibrated scoring framework the practice has spent years developing.

That last point matters more than people expect. A lot of bespoke AI software projects in professional services are building wrappers around general-purpose models with some prompt engineering and a client's logo. That is not a product. It is a service dressed as software, and the moment a client's own team learns to prompt effectively, the value evaporates. The practices with defensible products have something the model cannot replicate from public information: proprietary training data, a validated scoring rubric, a checklist developed from ten years of audit findings. That is the IP worth productising. The AI is the delivery mechanism, not the product itself.

A surveying business, for instance, might have spent a decade developing a dilapidations assessment framework that junior surveyors apply inconsistently. The product is not "AI for surveyors." The product is that specific framework, made consistent and scalable, accessible to practices that cannot afford to hire the senior person who developed it. The pricing conversation becomes: what is it worth to a five-person surveying practice to have senior-level dilapidations analysis on every instruction, without the senior-level fee? That is a question with a real answer, and it has nothing to do with what the build cost.

How do you run the reverse-engineer test before commissioning any code?

Run the reverse-engineer test before you commission a line of code. Be brutal about what portion of your value is genuinely automatable versus what lives in your specific judgement. If the unit economics hold, the next question is whether your method is differentiated enough to defend. If both answers are yes, you have something worth building.

If your method already works as a service and the numbers suggest a product is viable, the practical challenge is that most specialist practices do not have the engineering capacity to build and maintain recurring software whilst also running a consulting business. That is the gap our SaaS Product Build partnership is designed to close: we co-build the software with you, you bring the domain knowledge and the client relationships, and we share the upside rather than just charging you a project fee. The model only works if the underlying economics are sound, which is exactly why we start with the numbers.

Frequently asked questions

What is bespoke AI software in a professional services context?

Bespoke AI software, in a professional services context, is a purpose-built production system that encodes a practice's proprietary method — a scoring framework, an assessment rubric, a synthesis process — and delivers it consistently at scale, rather than relying on a consultant to apply it manually each time.

How is professional services AI pricing different from standard SaaS pricing?

Standard SaaS pricing is often benchmarked against competitor products or build cost. Professional services AI pricing should start from the value the tool delivers relative to the day rate it displaces, then work backwards to an annual contract value the buyer will accept — typically fifteen to thirty per cent of the value created. The build cost is a constraint to test viability against, not the starting point.

What is the biggest pricing mistake specialist consultancies make when productising their IP?

Anchoring on either the build cost or the existing day rate. The build cost produces a one-off licence model that funds nothing ongoing. The day rate produces enterprise pricing that prevents the scale needed to justify a product investment. Neither is a SaaS pricing model; both are consulting habits applied to a problem they do not fit.