Outcome-based pricing for embedded engineering

Outcome pricing is the right default for this model and most attempts at it end in an argument about time and materials. The failure is almost always in how the outcome was written.

The three tests

Observable rather than inferred. You can look at the system and say yes or no. "The triage service is processing live claims in production" is observable. "Triage is more efficient" requires a study.

A named measurer. A person or a system that takes the measurement, agreed before work starts. Not "we will assess at the end", which means two parties assessing differently.

Neither side can change success alone. Neither side can redefine success alone. Write down what the outcome is and what changing it requires, which should be a signed change to the contract rather than a conversation.

An outcome that fails any of the three will be argued about again at payment time.

Run a candidate outcome through all three before it goes into the contract, because an outcome can pass two tests and still fail the third in a way that is not obvious until payment day. "The model's accuracy exceeds 90 percent" looks observable and it can have a named measurer, yet it still fails the third test if either side can move the 90 percent threshold, the evaluation dataset, or the definition of accuracy after signature without the other side agreeing. The clause has to name the dataset and the exact metric, frozen at signature, or the number becomes negotiable exactly when it matters most.

The outcome that works

A defined system, running in production, for real users, by a named date.

It is unexciting, and unexciting is the point: nobody argues about whether a system is running in production the way they argue about whether a business metric moved for the right reason. It passes all three tests. Production is observable. The date is unambiguous. Real users can be counted. And "defined" matters most: the definition is in the specification, which is why the specification has to exist before pricing rather than after.

Add the two supporting terms and the structure is complete: what "defined" means, referenced to a document both parties signed, and a handover date after the production date.

Business-metric outcomes, and why they usually fail

"Reduce claims handling time by 30 percent." "Cut support ticket volume by a quarter." These sound like real outcomes and they are the ones that end in dispute.

The problem is control. The metric moves for reasons neither party owns: seasonality, a policy change, a reorganisation, a different product launching, users behaving unexpectedly. The vendor built exactly what was agreed and the metric did not move, or moved for an unrelated reason. Now you are arguing about attribution rather than delivery.

If you use a business metric anyway, and there are cases where it is the right risk to share, then agree four things in advance: the baseline and how it was measured, the measurement window, the other factors that cancel the measurement, and what happens if the metric moves for a reason nobody predicted. That last clause is the one everybody skips and the one that gets used.

A middle option that works well: tie payment to the system running, and a bonus to the metric. The vendor is paid for what they control and rewarded for what they influence.

Consider a concrete version of the failure to see why it recurs. A logistics company signs a contract with the outcome written as "reduce delivery delays by 20 percent within six months of go-live." The system goes live on schedule and works exactly as specified. Delivery delays fall by 12 percent in month one, then a fuel price spike changes routing decisions company-wide in month three, and the six-month number lands at 9 percent. Nobody disputes that the software works. What gets disputed is whether the vendor met the outcome, because the contract never said what happens when an external cause the vendor did not create changes the number. The system-running milestone would have been paid on day one with no argument. The business-metric milestone is still being negotiated months later.

The customer's obligations belong in the contract

This is the part buyers resist and it is what makes outcome pricing enforceable.

Most missed outcomes have a customer-side dependency in the chain. Access arrived late. The person who could approve the security review was on leave for three weeks. The data was not what was described. The subject-matter expert was reassigned.

A vendor who has taken outcome risk will price that uncertainty in unless the contract names their dependencies. So write them down:

Access set up and tested by a date. The first two weeks covers what this includes.

A named person who removes obstacles with an agreed response time.

A named decision-maker who can approve scope and, importantly, decline it.

The release path, with the real historic durations for each approval step rather than the published targets.

A named inheriting engineer for the handover, involved from the production phase.

And a clause stating what happens to the date if any of those are late. The honest version is that the date moves by the delay, and saying so in advance is cheaper than negotiating it under pressure.

This list reads like it favours the vendor, and it is worth saying plainly why it does not. A customer who refuses to name a decision-maker or an access date is not protecting themselves from vendor risk, they are removing the one thing that lets the vendor take on outcome risk in the first place. Without named dependencies, a vendor pricing an outcome has to price in the customer's own unpredictability, and that cost lands in the number either way, just without the transparency of a written clause. Naming the dependencies is how a customer gets a lower, fairer price for taking on the risk they actually control.

Milestones that mean something

Break the outcome into two or three payment points, each observable.

A structure that works: a portion at a working system on real data in a non-production environment, a portion at production with real users, and a portion at handover completion once the customer's engineer has released a change unaided.

That last milestone is the one worth insisting on, because it makes the handover a commercial event rather than a courtesy. Handover and exit covers the test.

Avoid milestones tied to documents. Paying for a design document rewards producing documents.

The public standard to point at

AWS stated that its forward deployed deployments are structured around shared goals and business results rather than billable hours, and that customers should be self-sufficient once an engagement ends. Its partner programme describes a methodology that runs from a business process through to demonstrating measurable results.

Useful in a negotiation: the largest provider in this market has committed publicly to outcome-based pricing and to customer self-sufficiency. A vendor who cannot match either has made a choice you should understand before signing.

That standard is also a useful check on your own contract before signature. If AWS's public commitment describes shared goals and measurable results rather than hours billed, and your vendor's proposal describes a day rate with a target date rather than a commitment, the gap between the two documents is the gap in what risk the vendor is actually willing to carry.

What we do

An agreed specification, an eval suite derived from it before the code exists, a named production date and a named handover date. The eval suite is what makes the outcome observable rather than a matter of opinion: it either passes or it does not, and it is the same artefact your team inherits.

That is also why we can take on outcome risk. The part of a build that used to make fixed pricing dangerous was how long the code takes to write, and that is no longer the main limit. Discovery and your approval path still are, which is why both appear in the contract as shared obligations rather than as our risk alone.

None of that removes the need for the customer-side clauses above. A specification and an eval suite fix the part of the risk that lives inside the build. They do nothing about an approver on leave for weeks or access that arrives late, which is why those obligations still get named, dated, and tied to a clause about what happens to the production date if they slip.