How to price forward deployed engineering

The rate matters less than what the pricing model pays the vendor to do. Here are the four, and what each one produces.

Time and materials

How it works. A day rate per engineer, billed as used.

What it pays for. Duration. The vendor's revenue rises with the length of the engagement.

Why that is a problem here. The main failure mode of this model is the engagement that never ends. Time and materials pays for exactly that. Nobody has to behave badly for it to happen: there is always one more improvement, and the incentive quietly agrees.

When it is still right. When the scope genuinely cannot be bounded and both sides know it, and when you have strong technical leadership of your own directing the work. At that point you are buying staff augmentation and should call it that, because it is an honest model with honest pricing.

How to make it safer. A cap, a production date, and a handover date. Without those three, a day rate is an open subscription.

Fixed scope, fixed price

How it works. An agreed scope for an agreed number.

What it pays for. Delivering the document.

Why it fits this model badly. The premise of forward deployment is that the scope is discovered by doing the work. A fixed-scope contract for work whose scope is unknown produces one of two things: a padded price that covers the vendor's uncertainty, or a change-request argument in month two. Usually both.

When it is right. When the scope is actually knowable, in which case you probably want a consultant or an integrator rather than this model at all.

Outcome-based

How it works. Payment tied to a defined result: a system in production by a date, a measured improvement, a milestone that means something operationally.

What it pays for. The thing you actually want.

Why it is the right default. It puts delivery risk on the party who controls delivery. It makes the endless engagement expensive for the vendor rather than profitable. And it forces both sides to agree, before starting, what success is, which is a conversation most engagements avoid until it is a dispute.

Why most attempts fail. The outcome is not measurable. "Improve claims triage efficiency" is not an outcome, it is a direction. If you cannot state on the day of signature how the measurement will be taken and who takes it, you have priced a hope. Outcome-based pricing covers how to write one that works.

The public precedent. AWS stated that its forward deployed deployments are structured around shared goals and business results, not billable hours. When the largest cloud provider commits to that in writing, a smaller vendor declining to has told you something.

Bundled into the licence

How it works. The deployment is included in a multi-year software contract, with no separate services line.

What it pays for. Getting you live, because the vendor's return comes from renewals rather than from the deployment.

Why it is attractive. The incentive is clean: the vendor wants you self-sufficient and successful, because that is what renews.

The catch. It only works with genuine multi-year commitment and enough contract value to absorb the deployment cost. And the deployment cost is in the price whether or not it is itemised, so ask what the licence would cost without it. a16z's Trading Margin for Moat describes this blended shape as the norm for the companies that made the model work: ServiceNow's gross margin at IPO was 63.2 percent and Workday's 54.1 percent, both climbing to 79 and 75 percent by 2024 as the services share converted into product.

What to actually do

Default to outcome-based, with the outcome written as a system running in production by a named date. That is the most measurable outcome available and it avoids the trap of trying to price a business metric neither side controls.

Add the two dates regardless of model. A production date and a handover date. These do more work than the pricing structure, because they bound the engagement whatever the rate.

Ask the diagnostic question. If this takes twice as long as scoped, who pays for the second half? The answer tells you which model you are really in, whatever the proposal is titled.

Price the handover separately if you must, and bound it. A defined support window with a fixed scope and a fixed end is honest. An open-ended retainer is how the dependency comes back through the side door.

From the vendor's side

Worth stating, since we are one.

Outcome pricing is harder for the vendor and it is the right thing to sell. It requires being able to estimate work whose scope is discovered, which means being disciplined about the specification and honest when the discovery invalidates the estimate.

Our version: a specification written to the level our tooling generates from, an eval suite derived from it, a named production date and a named handover date. The reason we can price on the outcome rather than the hour is that the code is AI-written and the suite is what proves it, so the variable that used to make fixed pricing dangerous, how long the typing takes, is not the binding constraint any more. What remains variable is discovery and your approval path, and we say so rather than pricing around it.

Next: how to write a measurable outcome, or what it costs from the buyer's side.