// 11 September 2026

How to Buy AI and Cloud Consulting

There are two honest ways to buy AI and Cloud consulting, and the one your procurement process prefers is the one that tells you the least about what you’re buying.

Series – this is part 2 of 3 on AI and Cloud consulting. Part 1: Why AI Projects Stall After Cloud Migration. Part 3: What Transformation Governance Is Actually For.

Every consultancy selection ends up in a comparison table. Columns for the suppliers, rows for the criteria, and one row that decides more than it should: the day rate.

The day rate wins that row because it’s the only number that fits in it. Every supplier can quote one. They look directly comparable. A procurement function can rank them without reading a single page of the technical response. Day rate is the worst available way to buy engineering, and it keeps winning because it’s the only number that fits in a comparison table.

This article is an argument about which number should replace it, and about what the choice of commercial model does to your programme before anyone writes a line of code.

What a Day Rate Actually Buys

A day rate transfers estimation risk from the supplier to you. If the work takes longer than anyone expected, you pay for the difference. The supplier’s exposure ends at their margin.

It also hands you a second job you didn’t want: policing effort. Somebody on your side now reviews timesheets, wonders whether the fourth week of “integration hardening” was necessary, and negotiates whether a half-day counts. That job has a real cost, it lands on your most senior engineering people, and it produces nothing. Effort was never the thing you wanted. You wanted the platform.

Worst of all, a day rate lets everyone skip the hard conversation. Scope stays vague because nothing forces it to be precise. The supplier finds out what the work really involves at your expense, one billed day at a time.

What a Fixed Price Forces

A fixed price forces the supplier’s estimate to absorb the risk. To quote a number they can survive, they have to interrogate the scope before signature: what the integrations touch, where the data actually lives, which of your systems will fight back. You find out what they truly believe about your programme before you sign, and the questions they ask during estimation are free diligence – the same discovery a day-rate engagement would have billed you for.

The discipline is measurable in delivery. We took a trades platform from MVP to production-ready in five months – quoting, invoicing, scheduling, mobile, integrations, AI pipelines. That scope was only estimable because the commercial model required it to be estimated. The same forcing function underpins outcome-shaped work like our cloud product development for an international broadcaster, which reached launch 50 percent faster than the client’s prior delivery model.

Table showing where risk sits under day rate versus fixed price: who carries the estimate, who polices effort, and when the buyer learns what the supplier believes

When the Day Rate Is Right

Neither model is free, and fixed price is wrong in specific, predictable places.

Genuine discovery can’t be fixed-priced honestly – nobody knows the scope yet, so a fixed number is either padded or fictional. Co-delivery inside your own team, where your people set the direction week to week, has no stable scope boundary to price against. And a product in fast iteration, where the roadmap moves faster than any statement of work, will bury a fixed-price contract in change requests until both sides hate it.

Our position, stated so you can hold us to it: fixed price wherever scope can be defined – a migration wave, a landing zone, a build tranche – and a timeboxed day rate where it genuinely can’t, with a named point where it converts. A day rate bought knowingly, for a bounded discovery with a conversion date, is a fair purchase of uncertainty. A day rate bought because the table needed a number is an unpriced risk transfer, and you’re the one holding it.

The Line Item That Gets Cut First

Whichever model you buy under, one scope item decides more of your total cost than the rate ever will: whether FinOps governance and policy-as-code exist from day one.

Bought on day one, the mechanism is cheap. Tagging standards are written before any workload exists, so everything arrives labelled. Budget alerts and spend forecasts run from the first invoice. Policy-as-code sits in the pipeline and blocks the untagged resource, the oversized instance, and the unencrypted bucket before they deploy. It’s configuration and habit, folded into work that’s happening anyway.

Retrofitted, the same capability becomes a programme. The trigger is usually the first genuinely frightening quarterly bill, and by then the estate is live. Tagging becomes archaeology across thousands of running resources with owners who’ve moved on. Policies applied to live workloads break them, so every guardrail needs testing against production. Cost visibility often requires re-architecting the very things that were built quickly in the ungoverned window. And the work now competes for the same engineers who were hired to ship features, under a steering group of its own.

No public dataset quantifies the day-one-versus-retrofit delta directly, so we won’t invent one. The scale of what runs ungoverned is public, though: in Flexera’s 2026 State of the Cloud report, organisations themselves estimate that 29 percent of their cloud spend is wasted – the first rise in five years, driven substantially by AI workloads. Nearly a third of the bill, self-reported, by the people paying it. That’s the number a comparison table never shows.

Diagram comparing FinOps governance and policy-as-code bought on day one with retrofitting them after the first bad quarterly bill, alongside Flexera 2026 finding that 29 percent of cloud spend is self-reported as wasted

How to Buy It Well

None of this requires abandoning procurement discipline. It requires pointing the discipline at better rows.

Ask every supplier to fixed-price the first definable tranche, and compare those quotes with their stated assumptions and exclusions – the assumptions are where the truth lives. Score the questions each supplier asks about your scope; the ones who ask hardest are pricing risk they intend to own. Make FinOps governance and policy-as-code an explicit contract line with a day-one start, so it can’t be quietly descoped when the timeline tightens.

And write the ending into the beginning: who owns the platform when the engagement closes, named in the contract. The cost of leaving that blank is the subject of Why AI Projects Stall After Cloud Migration.

Q&A: Buying AI and Cloud Consulting

Is fixed price always cheaper than day rate?
No. A fixed price includes the supplier’s risk premium, so the sticker can be higher than an optimistic day-rate forecast. The difference is that the fixed number is real and the forecast isn’t – day-rate engagements are priced at their best case and delivered at their actual one. You’re choosing between visible risk pricing and invisible risk transfer.

How do we compare consultancies without a day-rate column?
Fixed quotes on an identical first tranche, read alongside each supplier’s assumptions and exclusions. Add the questions they asked during estimation, and references focused on outcomes delivered against a committed number. That table takes more effort to build than a rate card. It also predicts the engagement.

What belongs in the contract from day one?
Tagging standards, budget alerting, and policy-as-code guardrails as delivery scope in the first tranche. Named ownership of the platform at handover. Exit provisions that include documentation and automation, so what you bought survives the supplier leaving. All three are cheap on day one and expensive as retrofits.

When should we accept a day rate?
For a bounded discovery, for co-delivery your own team directs, or for a product moving too fast for a stable statement of work. In each case, timebox it and agree in advance the point where it converts to a committed price. A day rate with no conversion point is a scope conversation both sides have agreed never to have.

The series continues – part 1, Why AI Projects Stall After Cloud Migration, makes the case for who owns the platform after cutover. Part 3, What Transformation Governance Is Actually For, asks whether the governance above it all would notice any of this going wrong.

Working Through This With Vertex Agility

Our AI and Cloud consulting practice prices the way this article argues: fixed where scope can be defined, honestly day-rated where it can’t yet, and FinOps governance in the first tranche rather than the first crisis.

If you’re shaping a programme and want a commercial model argued against your actual scope, talk to us – a senior consultant will come back within one working day with a view on what’s estimable now, and what honestly isn’t.