What outcome-based pricing means for AI work

The model most AI work still runs on

Day rates and time-and-materials reward effort, not outcomes. The longer a build takes, the more the supplier earns, so the incentive points away from your result. You carry the delivery risk; the contractor carries none. When the engagement closes, the knowledge often walks out with them.

The numbers bear this out. A McKinsey study with the University of Oxford found large IT projects run, on average, 45 per cent over budget while delivering 56 per cent less value than predicted. Paying for time does not buy you the result. It buys you the attempt.

How outcome-based pricing works

Three things are agreed before any code is written: the outcome you need, how it will be measured, and what it is worth to the business. Payment follows the result, not the timesheet.

• Frame the outcome and its value, not a scope of hours.
• Agree the measure before the build starts, so success is not argued about after.
• Settle against the result, so the supplier only wins when you do.

Where it fits, and where it does not

Outcome-based pricing is not right for everything. It needs an outcome both sides can name and measure. Open-ended research, or a brief that amounts to "explore AI", does not qualify, and pretending otherwise just hides the risk again.

When the outcome is clear and valuable, though, it aligns incentives better than any contract clause. The supplier is paid to deliver the result, so the result is what gets built. That is the test worth applying to any AI engagement: is the person building it paid for your outcome, or for their time?

What you keep

The point of the model is where the value lands. You are left with working systems in production, the code and documentation behind them, and a team that can run and extend the work without us. The value is yours to keep.