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 rewards it.

When it is still right. When the scope genuinely cannot be limited in advance 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.

A worked comparison. Two vendors quote the same deployment. Vendor A prices $18,000 per engineer-month, uncapped, with no production date in the contract. Vendor B prices the same deployment at a fixed $95,000 for a system in production within five months, with a named handover date two months after that. Vendor A looks cheaper per unit, and on a deployment that runs its planned five months the two prices are close. The difference shows up if discovery finds more than expected, which it usually does. Vendor A's price then keeps rising with no natural stopping point. Vendor B's price is fixed, and the vendor now has an incentive to solve the problem rather than bill for encountering it.

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 raised 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 agreed to pay for something you cannot check. 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 simple: the vendor wants you self-sufficient and successful, because that is what renews.

Who this fits. A vendor whose product genuinely needs deployment help to reach value, sold at a contract size where a multi-year commitment already covers the deployment cost several times over. It fits software procurement more naturally than services procurement, which is often the actual reason a buyer prefers it: one signature and one invoice line, instead of a separate services statement of work that needs its own approval.

The catch. It only works with genuine multi-year commitment and enough contract value to cover 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 combined structure 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 rising 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 mistake 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 matter more than the pricing structure, because they limit 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 limit it. A defined support window with a fixed scope and a fixed end is honest. An open-ended retainer is how the dependency returns without anyone noticing.

Read the proposal for what it pays the vendor to do, not what it says it does. A proposal can be titled "outcome-based" and still describe a scope of deliverables with a payment schedule tied to dates rather than to the outcome itself, which is fixed-price wearing a different label. The tell is whether the document names a measurable result and a named measurer, or whether it names a list of activities and calls the last one the outcome. If the last line item is "handover documentation delivered," that is fixed-price. If it is "customer's engineer releases a change unaided," that is an outcome. Outcome-based pricing covers how to tell the difference and how to write the second version.

What changes when the vendor sells more than one pricing model

Most vendors offer more than one of these four, and the choice they steer you toward in a sales conversation is informative on its own. A vendor who defaults every prospect to time and materials, regardless of how well the scope is understood, is optimising for their own revenue predictability rather than yours. A vendor willing to discuss outcome pricing but who cannot answer the diagnostic question about who pays for a doubled timeline has not actually thought through the model; they are offering the label without the substance. Ask the question early in the sales process, before a proposal is drafted, because the answer changes how the rest of the negotiation goes.

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 writing the code takes, is not the main limit any more. What remains variable is discovery and your approval path, and we say so rather than pricing around it.

That last point is worth restating on its own, because it is the honest limit of what any pricing model can promise. Nobody can price away a customer's own approval timeline, and a vendor who claims to have solved that with a clever contract structure is not being straight with you. What a good contract does is name the dependency, put a date on it, and say what happens to the production date if the dependency slips. That is the whole job of the pricing structure: not to eliminate uncertainty, but to say in advance who carries it.

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