AI consulting cost for mid-market companies

PRIONATION's structure is fixed and public: a Diagnostic at €5,000–7,000 over two weeks maps the bottleneck and sets the scope; a Build at €25,000–55,000 over eight weeks ships the production system; a Retainer at €4,000–9,000/month keeps a pod available afterwards, with a six-month minimum. A three-page Express Site starts at €1,500.

More than 60% of Diagnostics proceed to a Build — a number that only holds because the Diagnostic is scoped to qualify the work, not to sell the next stage regardless.

AI work is sold three ways. Hourly or time-and-materials shifts all the risk of unpredictability onto you — the meter runs whether or not the work converges. Fixed-scope prices a defined outcome, so the vendor carries the variance. Retainer buys ongoing capacity at a predictable monthly rate.

The structural point: time-and-materials rewards the vendor for the work taking longer. Fixed scope only works if the vendor has a method that removes variance — which is why fixed price and methodology are inseparable.

The costs vendors underplay are ramp, integration, and lock-in. Ramp is the weeks billed while a team learns your domain. Integration is the unglamorous work of connecting to your real systems, often scoped vaguely and billed as it expands. Lock-in is the deferred cost of a system you cannot operate or leave without the vendor.

A fixed-scope engagement with owned infrastructure removes all three: ramp and integration are inside the fixed price, and there is nothing to be locked into because you hold everything.

Budget the Diagnostic first — it is small, and it is what makes the Build price reliable. Treat any vendor who quotes a fixed Build price without a scoping step as either guessing or planning to bill the difference later.

For total cost of ownership, count what you keep: with owned infrastructure the Build is a capital asset your team can run, not a subscription to someone else's system.

The hardest part of an AI buying decision is rarely the headline number — it is that two quotes for the 'same' project describe different things. One vendor's €30,000 covers a working prototype; another's covers a production system with evals, telemetry and a handover. Neither is lying, but they are not comparable, and a side-by-side spreadsheet of day rates obscures exactly the difference that matters. The only way to compare honestly is to normalise on the deliverable, not the price: what runs in production at the end, who holds it, and how 'done' is defined.

A practical method is to write your own definition of done first — the workflow, the measurable success criterion, the systems it must connect to — and ask every vendor to price against that single specification. When the deliverable is fixed, the prices become comparable and the gaps become visible: a quote far below the others is usually missing integration, evals, or ownership, and that omission is a cost you will pay later rather than a saving. This is the same discipline a Diagnostic produces, which is why a quote anchored to a scoped Diagnostic is more reliable than one given cold.

The honest limit is that no specification removes all judgement — a cheaper team may simply be more efficient, and a dearer one may be padding. But a fixed deliverable converts a vague 'who is cheaper?' into a precise 'what is each price actually buying?', and that question almost always answers itself once the deliverables are laid side by side.

The lowest quote is frequently the most expensive engagement, because the gap between it and the others is rarely margin — it is scope that has been quietly left out. A price that omits eval scaffolding ships a system no one can prove is working; one that omits telemetry ships a system no one can debug; one that omits owned infrastructure ships a dependency you pay for indefinitely through a hosting or 'platform' fee. The cheap number buys the build and defers the rest into costs that surface after the contract is signed, when your leverage is lowest.

The pattern to watch for is the fixed price quoted with no scoping step. A vendor who names a Build figure before mapping your data, your integration points and your definition of 'working' is either absorbing hidden risk they will later renegotiate, or planning to convert to time-and-materials the moment the work proves harder than the demo suggested. Both routes end at the same place: the quoted number was a marketing figure, not a commitment, and the real cost is discovered in flight.

What this cannot fix is a buyer who optimises for the lowest line on a quote regardless of what it contains. The defence is to price total cost of ownership, not the build alone — count the recurring fees, the work you will have to redo, and the exit cost — and to treat a suspiciously low quote as a question to ask rather than a saving to bank.

A build is a one-off line; ownership is a recurring one, and the two behave very differently over three to five years. A rented system — hosted by the vendor, with the logic in a proprietary layer — has a low entry price and a monthly fee that never ends, plus an exit cost that grows the longer you stay. An owned system has a higher visible build cost and then a running cost you control: model-provider usage, hosting in your own accounts, and whatever maintenance you choose, whether that is an optional Retainer or your own team. Over a multi-year horizon, the recurring line dominates the comparison, and the cheaper-looking rented option is frequently dearer by the second year.

The variable most buyers underweight is the exit. With a rented system, leaving means rebuilding, because nothing portable comes with you. With owned infrastructure — code in your repository, infrastructure defined as code, model accounts and telemetry in your names — the exit cost is effectively zero, and that optionality is worth real money even if you never use it. A Retainer in this model is a choice renewed on value rather than a fee you cannot escape, which keeps the ongoing cost honest because it can always be cancelled at the six-month boundary.

Modelling total cost of ownership properly also reframes the build figure itself. A €25,000–55,000 Build that produces a capital asset your team can run is not the same kind of spend as the same sum paid for access to a system you never hold — the first appears once on the balance sheet as something you own, the second recurs forever as something you rent.

The most useful questions about price are not about the number at all. Ask who holds the code, the cloud accounts and the model keys at the end — if the answer is 'we host it for you', the headline price is an entry fee to a subscription, not the cost of an asset. Ask how 'done' is defined and measured — if there is no eval suite, there is no agreed finish line, and any fixed price quoted against an undefined finish is a guess. Ask what happens if production quality drifts after launch — a real warranty names a measurable threshold and a window; a vague 'we'll support you' is not a commitment you can hold anyone to.

Then ask the incentive question directly: under your model, do you earn more by finishing or by continuing? The answer reveals whether the vendor's interest is aligned with yours before a single line is written. Pair it with a request to see the scoping step — a vendor confident in a fixed price will have a mechanism, like a paid Diagnostic, that maps the variance before committing to a number, and will be able to explain why the price holds rather than asking you to trust that it will.

A red flag worth naming plainly: a vendor who resists every one of these questions, or who answers them only with reassurance rather than mechanism. Ownership, evals, warranty and a scoping step are not premium extras — they are the structure that makes a fixed price honest, and their absence is not a discount but a deferred bill.