Outcome-based pricing for embedded engineering

Outcome pricing is the right default for this model and most attempts at it collapse into a time-and-materials argument. 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.

No unilateral goalpost movement. 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 relitigated at payment time.

The outcome that works

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

It is unexciting and it passes all three tests. Production is observable. The date is unambiguous. Real users can be counted. And "defined" does the heavy lifting: the definition sits 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 confounders that void 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.

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 provisioned and tested by a date. The first two weeks covers what this includes.

A named unblocker 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 slip. The honest version is that the date moves by the delay, and saying so in advance is cheaper than negotiating it under pressure.

Milestones without the theatre

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

A shape 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 shipped 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-shaped pricing and to customer self-sufficiency. A vendor who cannot match either has made a choice you should understand before signing.

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 carry 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 binding constraint. Discovery and your approval path still are, which is why both appear in the contract as shared obligations rather than as our risk alone.