What Should AI Consulting Cost? Make-or-Buy, Honestly Calculated

One of the most common questions managing directors put to me is: what should one of these AI things actually cost? And almost every time, it's the wrong question. Not because money is irrelevant. But because the day rate or the licence price is only the visible part of the sum. The real question is: what is this worth to me, and who carries the risk if it goes wrong? Let's get to the point.

I look at investments like these from the perspective of someone who audits rather than sells. I've conducted audits in five industries and five countries, from aviation to precision engineering. And the same pattern shows up again and again: it isn't the price that decides between success and failure, but whether someone did the honest arithmetic beforehand. Make or buy. Build in-house or buy in. That question belongs at the start, not at the end.

The wrong question and the right one

"What does AI cost?" is about as useful as asking what a machine costs. The counter-question is always: which machine, for which part, in what volume, to what tolerance? Only then can you talk money. With AI it's exactly the same. Without the process behind it, any price is a guess.

So the right first question isn't the price but the value. What does the process cost me today, in time, in errors, in lost orders? If an employee spends hours every day copy-pasting between two systems, that has a clear price. Only once that value is on the table can you judge whether tens of thousands of euros for a bought-in solution is a lot or a little.

"What does it cost?" is the wrong question. "What is it worth to me, and who is liable if it goes sideways?" is the right one.

What buying really costs

When buying in, most people look only at the price on the quote. But that's rarely the whole sum. On top come the costs that only surface later and that, over the years, often exceed the purchase price. Factor these items in from the outset:

• Roll-out and adaptation: day rates for consulting and customisation, often four figures per day, add up faster than you'd think.
• Ongoing licence or subscription: what flows out every month for as long as you use the tool.
• Dependence on someone else's update cycles: you get changes when the provider ships them, not when you need them.
• Exit costs: what does it cost to get back out again once your data sits with the provider?
• Missing in-house knowledge: if nobody at your company understands what the thing does, you pay extra for every question.

Dependence in particular is underestimated. I've seen businesses that weren't allowed to update because a provider lock-in period was running, while at the same time their cyber insurance demanded current security patches. Two contracts, one conflict, and the mid-sized firm was caught in the middle. Anyone who isn't master of their own data and update cycles buys, alongside the tool, a slice of being controlled from outside. That appears on no quote, but in a crisis it costs the most.

What building really costs

Building it yourself sounds like control and like saving money. Both are true, but only under certain conditions. With AI-assisted development you can now build an impressive prototype astonishingly fast. But the prototype is the cheap part. What comes afterwards is where it gets expensive.

A tool that carries real business processes needs more than a working demo. It needs a clean data architecture so the results hold up. It needs tests so that an update doesn't quietly break something else. It needs security, because real company data flows through it. And it needs maintenance, because software ages. Leave out those four things and you're not building an advantage, you're building a risk with a pretty surface.

Then there's the bus factor, a question I raise in every sparring session: what happens if the one person who built this drops out? Parental leave, a new job, illness. If nobody else understands the tool, your own solution is just as much a dependency as the bought-in one, except that the provider sits inside your own building and might resign tomorrow. Building is no free pass. It only shifts where the responsibility lies.

Who's financing whose research here?

One line makes my ears prick up: "We'll deliver the numbers after the needs assessment." If, at the end of a paid analysis, there's no tangible result but only the recommendation to keep consulting, then you're paying for the provider's learning curve, not for your own progress. That's human, but you should recognise it and name it.

Serious consulting makes itself redundant by making you capable of acting. At the end of a good analysis, something concrete is on the table: a process map, a decision paper, a clear make-or-buy comparison with numbers. Something that stays in your company and keeps working even without the consultant. So ask up front exactly what will be there at the end. Anyone who can't answer that clearly is selling you time, not a result.

The same goes for large standard systems. Four-figure day rates for adapting a well-known system are normal in the market. The question isn't whether that's a lot, but whether the adapted result ultimately belongs to you, or whether you have to queue up again for every further change. Whoever pays should, in the end, also own what they paid for.

The honest make-or-buy calculation

A sound calculation doesn't begin with the tool but with the process. First the process, then the tool, then the AI. As long as the workflow is unclear, all you automate is the existing mess, faster and more expensively. AI set on top of a broken process delivers the same error, but now a thousand times over and stamped "objective".

Once the process is settled, don't compare purchase price against build effort, but the total cost over three to five years. On both sides, that includes roll-out, ongoing operation, maintenance, security and exit. And on both sides it includes an honest answer to two questions: who ultimately owns the data? And who inside your own company understands the thing well enough to audit it and, in an emergency, switch it off?

A rule of thumb from practice: buy standard tasks, build special ones. A problem that a thousand other businesses have in exactly the same way is usually cheaper and safer to buy in. A workflow that is your unique selling point and fits nowhere off the shelf argues rather for your own lean solution. The expensive mistake is confusing the two: buying the distinctive off the shelf and laboriously building the standard yourself.

Three cases from the mid-market

So this doesn't stay abstract, here are three typical situations and how the make-or-buy question turns out in each:

• An AI that pre-sorts job applications: this is standard and, at the same time, sensitive, because people are affected. Here much argues for an audited, bought-in system with clear documentation, because the legal requirements are high and a home-built sorter with no bias check is a genuine risk.
• A camera with a model that inspects components in final inspection: everything here hangs on your parts, your tolerances, your lighting. This is rarely off the shelf, and the data is your capital. Often a proprietary or tightly adapted solution pays off, one whose model and data belong to you.
• An AI that creates orders in the ERP: this depends entirely on your specific ERP and your master data. Buying often fails on the missing interface; building only pays off if the process is cleanly settled beforehand. Here it's the homework of process clarity that decides, not the price.

Three cases, three different answers. That's exactly the point: there is no blanket rule and no blanket price. There is only the honest calculation for your process specifically.

What an auditor sees in the cost question

A salesperson wants you to buy. An auditor wants it to hold up. For the cost question that means: the cheapest tool can become the most expensive if nobody can operate it, audit it or, in an emergency, switch it off. I've seen businesses that bought a solution because the presentation was good and, a year later, paid twice, once for the tool and once for the clean-up work.

That's why every make-or-buy calculation has to include the question of responsibility and traceability. Who checks the output, by what rule, who signs off at the end. That isn't paperwork, it's risk control. This very mindset also sits inside a management system for AI to ISO/IEC 42001: named responsibility, checked output, documented processes instead of gut feeling. An investment that builds this in is rarely the cheapest on the quote and almost always the least expensive over the years.

In the end, the cost question for AI is the same as for a new supplier in manufacturing. Nobody would put a supplier into series production without vetting, just because the price was right and the sales rep was likeable. References, traceability, clear responsibility, an exit route. Apply those standards to an AI investment and you automatically ask the right question. Not "what does this cost?", but "what is it worth, and who stands behind it in the end?"