Fixed Fee, Day Rate, or Outcome: AI Project Pricing

A pricing model is a contract about who pays for being wrong.

AI project pricing comes in four shapes: a fixed fee, a day rate, a day rate with a ceiling, and a share of the outcome. Each one is a working answer, and each one quietly pays the supplier to behave in a specific way. A fixed fee pays them to defend the scope. A day rate pays them to keep going. A capped rate pays them to protect the cap. An outcome deal pays them to move whichever number you agreed to measure, which is not always the number you care about. Choose the model that matches how well the work is specified, not the one that feels safest. Buyers who invert that end up with the shape that looks most protective and behaves worst.

AI pricing models, and what each one rewards

Fixed fee. One number for a defined deliverable. The supplier carries the estimating risk, and prices it: a fixed quote written against a brief nobody has investigated typically carries 30 to 50 per cent of padding, because the supplier is pricing the range of things your brief might turn out to mean. It rewards scope discipline on both sides, which is genuinely valuable, and it rewards the supplier to read every request as out of scope once the money is fixed. Best when the specification is complete and the supplier has built something close to it before.

Day rate, or time and materials. You pay for the hours. In Western Europe a senior engineer at a specialist firm runs roughly €600 to €1,100 a day, and a blended team at a large consultancy sits well above that. The buyer carries the estimating risk, and gets flexibility in return: changing your mind in week four costs money instead of a negotiation. It rewards honesty about unknowns and it rewards nobody to finish early. Best when the work is genuinely exploratory and you have someone internal who can read a weekly burn-down and act on it.

Capped time and materials. Hours billed as worked, with a ceiling neither side can pass without a written amendment. The risk splits: you pay only for what happens, the supplier eats the overrun above the cap. This is the shape most SME builds should use and the one least often offered, partly because it requires the supplier to be confident enough in their estimate to write it down. Ask for it by name.

Outcome or success-based. Part of the fee depends on a measured result: hours saved, cases handled, response time, conversion. It sounds like perfect alignment and it is the rarest of the four for reasons covered below. Where it genuinely works, it works because both sides trusted the same baseline before anyone started.

Those four AI pricing models cover the build. A fifth shape appears after launch and belongs in the same conversation. A monthly retainer covers monitoring, maintenance and a response time, and it is where the relationship actually lives once the build is finished. Price it at signing, not a year later when you have no alternative supplier and no documentation.

Why a fixed price AI project can be the riskiest option you buy

The useful input is not your risk appetite. It is how much of the work is already specified, and there are three honest states.

Specified. The process is documented, the systems are named, somebody has looked at real records, and the acceptance criteria are written. Take a fixed fee. You have removed most of what the padding was covering, and a supplier who still pads at 40 per cent against a real specification is telling you they do not want the work.

Partly specified. You know the process and the target, and nobody has confirmed what the data looks like or how the integrations behave. This describes most SME AI projects at the point of quoting. Take a capped time and materials arrangement, with the cap set after a paid discovery rather than before it.

Open. The question is whether the thing is possible at all. Take a day rate for a short, bounded piece of work with a stop date, and treat the output as a decision rather than a system. A fixed price here is a fiction that both parties have agreed to pretend about, and the pretence collapses in week five, usually into a change-request argument that costs more than the flexibility would have.

The reason a fixed price AI project goes wrong is rarely dishonesty. It is that AI work has a variance profile closer to research than to building a website: the same brief can be four days or four weeks depending on what the data turns out to contain, which is exactly the source of the price spread across the market. Fixing the price does not remove that variance. It moves it into the contract, where it comes back as a scope argument.

Buy discovery separately, and own what it produces

Every argument above resolves the same way. Price discovery on its own, as a small fixed-fee engagement with its own deliverable, then price the build against what discovery found. Two weeks is a normal length for an SME project. You are buying an answer, not a relationship, and three things make it worth the money.

• It collapses the padding. The supplier no longer prices a range of possible projects. They price the one you have, and the quote drops or rises for a reason you can read.
• It is a competitive document. A written scope with a measured baseline can be sent to three suppliers who then quote the same thing. Without it, you are comparing quotes for three different projects and calling it a shortlist.
• It is a cheap way to hear no. A supplier who finishes discovery and recommends a smaller build, or none, has just saved you the larger number. That happens often enough to be worth the two weeks on its own.
• It tests the supplier before the money is committed. How they run two weeks is a fair sample of how they will run twelve.

One condition makes or breaks it: you own the output. The scope document, the baseline measurements and the option costings should be yours to take anywhere. Our audit works that way, and the first two weeks of an implementation are the same two weeks bought separately, which is the point.

Milestones, retention, and the first change request

Tie payments to acceptance, not to the calendar. A date passing proves nothing and a milestone that says end of month 2 is a payment schedule wearing a project plan. Four gates cover most builds: discovery delivered, design and acceptance criteria signed, the system passing the agreed evaluation set in a test environment, and production acceptance with the documentation handed over. Hold 10 to 20 per cent until that last gate, because handover documentation written after final payment is documentation that does not get written.

Change requests need a rule before you need one. Agree a threshold in the contract: anything under half a day is absorbed, anything above it is priced and logged in writing before work starts. That single clause removes the two failure modes at once, the supplier nickel-and-diming a request that takes an hour, and the buyer accumulating twenty small requests that add up to three unbilled weeks and a resentful team.

The first change request is the most informative moment of the engagement. A supplier who prices it fairly, explains what it displaces and asks which item you want to drop in exchange is behaving like a partner. One who absorbs everything silently is either padding elsewhere or building resentment that will surface in month four. The WA Center platform ran across four countries with several distinct user roles, and phasing it by acceptance gate rather than by calendar month is what kept the scope legible while the requirements moved underneath. The rest of our case studies were structured the same way.

Why outcome pricing is rarer than it should be

Paying for results is the most reasonable-sounding request a buyer can make, and it fails on attribution more often than on principle. Your support volume fell 30 per cent in the quarter the assistant launched, and you also changed the pricing page and hired two people. Deciding what the system is owed requires a counterfactual nobody has, and the argument arrives exactly when the invoice does.

The second problem is that a measurable target is a target somebody optimises. Pay for tickets closed and tickets get closed. Pay for hours saved and the hours get counted generously. This is not a moral failure, it is what happens to any metric with money attached, and the fix is a metric that is hard to move without also moving the business, which is harder to write than to describe.

The third is cashflow. A specialist firm of six people cannot carry six months of delivery against a payment that may not arrive, so the ones who offer pure outcome pricing either charge a multiple that makes it expensive when it works or are funding it from somewhere you should ask about. Where outcome pricing does earn its place is as a slice: 70 to 85 per cent of the fee on delivery milestones, the remainder against a single metric measured at a fixed point, with the baseline agreed in writing before the build starts. That last condition is the one that gets skipped, and skipping it turns the bonus into a dispute.