Contracting for Outcomes in the AI Era

Let me start with two questions that keep coming up in conversations with clients:
If an AI-assisted engineering team delivers the same result in half the time, what exactly should the customer pay for? And what should the vendor get paid for?

For years, the answer was relatively simple: clients either bought people’s time, or agreed on a scope and a price. Time and materials or fixed price, both models have served us reasonably well. But, now with AI, human effort and delivered value are no longer as closely connected as they used to be.

The Productivity Paradox

Take a traditional T&M engagement. If AI makes our engineers 30% more productive, the customer needs fewer person-days to get the same amount of work done.

For us as a vendor, becoming more productive means reducing revenue from that engagement. Yes, we can use the freed-up capacity elsewhere. But there is still something strange about a commercial model where getting better at your job means you can invoice less.

Fixed price has almost the opposite problem. Say we agree to deliver something to a client for €1 million. If AI allows us to do it with substantially less effort, most of that productivity gain stays with us. At some point, the customer will reasonably ask about their share of the AI productivity gain.

I think both models will survive, but not untouched.

So What Should the Clients Pay For?

One option is to stop paying for time and start paying for accepted units of work, like a migrated application, a resolved vulnerability, an automated test, or a successfully modernized piece of legacy code.

Another is to keep buying the capacity of a delivery team, but care less about how that capacity is composed. The vendor commits to throughput, quality and lead time and decides how much of the work is performed by people, AI-assisted engineers or agents. That’s already quite different from buying five developers for twelve months.

Then we can go further and contract for an actual business outcome. Some examples of business outcomes might be reducing application operating costs, increasing straightthrough processing or shortening customer onboarding. Now part of the vendor’s fee depends on whether that actually happens.

And agents create another interesting option. If an agent performs a well-defined business process end to end, why not pay per completed transaction? Again, some examples of “completed transactions” might be a claim processed correctly, a customer request resolved, a document checked, or a support case completed without human intervention.

At that point, does the customer really care whether the transaction required two people, three agents, five models and a million tokens?

Examples of outcome-based payment models

Outcomes Are Harder to Define Than Person-Days

Of course, there is a reason person-day-based contracts have been around for so long. Person-days are easy to count, while business outcomes aren’t.

Imagine we agree to reduce customer onboarding time for a bank from three days to three hours. We build the technology, automate decisions and introduce AI. Six months later, onboarding still takes two days. What happened?

Maybe there is a compliance approval outside our control that still takes 36 hours. Maybe the client didn’t make the process changes we agreed on. Maybe the data wasn’t available when it was supposed to be. And now imagine that 20% of our fee depends on the answer. Suddenly, this affects our income and P&L.

What we need is a baseline, measurable KPIs, and explicit dependencies. And, most importantly, it needs to be clear about what each side can actually control. This is why I think hybrid models are probably the pragmatic place to start: a base fee for the work, a success fee tied to the outcome, and outcomes broken down into components the vendor can actually influence.

Both Sides Have to Change – Clients and Vendors

There is an uncomfortable part of this for vendors like us. If we want to get paid for outcomes, we need to accept some commercial risk.

We also need to understand the customer’s business much better than we do when we’re simply supplying engineering capacity. And we need to get better at measuring what we actually contributed.

But clients have to change too. We cannot ask a vendor to commit to an outcome while keeping that outcome vague, someone on the business side needs to own it. Baselines and dependencies need to be clear, and data needs to be available.

The vendor needs some freedom in deciding how the work gets done. Sentences like I want to pay for the result and I want to specify exactly how many people of which seniority must work on it do not go togehter. Those are two different economic models.

—

We are still learning where these models work and where they create more complexity than value. I certainly don’t think every software project should suddenly become an outcome-based contract. But I do think that five-year buying frameworks built primarily around person-day rates belong to a world that is disappearing.

AI-assisted engineering will keep weakening the relationship between hours worked and value delivered. Agents will perform larger pieces of work independently. And reusable assets and accelerators will allow us to start further ahead instead of rebuilding the same foundations for every customer. Our commercial models will have to catch up.

For vendors, that means accepting that our future cannot be based on selling more effort. For clients, it means getting better at defining and measuring what they actually want to achieve.

Perhaps the best outcome of the AI era will be that we spend less time negotiating the price of an hour and more time agreeing on the value of an outcome.