FDE Economics: Margins, Outcome Pricing, and When to Stop

Forward deployment costs like services and has to earn like software. That sentence is the whole chapter. Everything else is the conditions under which it is possible and the signals that tell you it is not.

An engineer on site at one customer for a quarter is a payroll line against one contract. That is a services margin, and no amount of calling the person a forward deployed engineer changes the arithmetic. What changes it is whether the engagement produces something that every later customer gets for less, and whether the pricing captures the result the engineer guaranteed. If both happen, the services cost was an investment. If neither does, you have started a consulting firm with a venture-backed burn rate.

The short version

Forward deployment compresses gross margin in the short run, and the model only earns it back if the deployment-to-product loop closes and the pricing puts the vendor's revenue behind the outcome. Outcome pricing is the reason the model is spreading: billing per result requires someone to guarantee the result, and that is the FDE. The buyer's objection is lock-in and dependency, and it is legitimate, but the fix is contractual: the observation record and the configuration belong to the customer and port with them. The signal to stop sending engineers is when the product's configuration surface has absorbed enough that the customer, or their own AI engineer, can deploy from the product. That was the goal all along. A company that never reaches it has not built a product. It has built a staffing agency with an API.

The margin math

Start with what the objection gets right. Sacra named implementation intensity as Sierra's biggest scaling risk, and the concern is fair: high-touch deployment compresses margins and gates growth on engineer hiring. Every deployment needs a person. People do not scale like software.

Palantir ran this trade for a decade and the number worth knowing is that until 2016 it employed more FDEs than product engineers. That is the cost side of the loop. What made it work was the other side: roughly $1.5 million in revenue per employee, per Plank's figure, with almost no traditional sales force, because the FDEs were the sales motion and what they built became product. The services cost bought two things at once, the deployment and the roadmap.

If your loop does not close, you pay the cost and get one of the two. That is the entire difference between the companies for which this model works and the ones for which it is a slow way to discover they are a services business. I covered the loop in the deployment-to-product chapter. The economics do not exist without it.

Why outcome pricing forces the question

Here is the part that makes the model unavoidable rather than optional.

Seat pricing never needed a guarantor. The customer bought seats, the vendor delivered software, and whether the software produced a result was the customer's problem. That arrangement is what the AI business models argument says is ending: software priced per seat is priced against a labor cost that AI removes, so the price has to move to the outcome.

The moment it moves, someone has to guarantee the outcome. Meurer's framing from inside Sierra is the cleanest I have seen. Agents push software pricing into the outcome quadrant. Outcome pricing requires the seller to guarantee the result. The question of how you guarantee it has one answer, and it is forward deployed engineering.

So a vendor pricing on outcomes is not choosing whether to have FDEs. It is choosing whether to name them. The cost is already in the pricing model. This handbook's pricing for AI products chapter covers the pricing side. The FDE is the delivery side of the same decision.

The buyer's side of the table

I want to give the objection its full weight, because it is the strongest argument against the model and it comes from people who are not wrong.

Andrew Ng has warned that letting a vendor's forward deployed engineers wire your processes to their stack significantly reduces optionality, and that a company's own AI engineer, on staff and building across models, is the structurally better bet. Plank's guide lists the three risks a buyer should hold: dependence deepens while the FDE is helping, capability does not transfer if the FDE ships without documentation or enablement, and Gartner expects enterprises to abandon FDE-heavy engagements on cost grounds. It also cites the figure that deployment is only about 20 percent of an AI system's lifetime cost, with the rest in operation and change, which means an FDE who leaves after go-live has helped with the small part.

All three risks are real. They are also all solvable in the contract, and a vendor who will not solve them there is telling you something.

The observation record belongs to the customer. What the agents did in your org, what got reversed, what got escalated, ports with you in a form you can load elsewhere. The configuration belongs to the customer. Every workflow, mapping, and threshold the FDE built is readable and exportable, not buried in the vendor's code. Enablement is a deliverable with a test: the customer's own engineer can change the configuration without the vendor by day 60, or the engagement is not done. If a vendor agrees to those three, Ng's optionality concern is answered. If they will not, the concern was correct.

I am on the vendor side of this table with Heidi, and I would rather write those terms myself than have a buyer extract them. A vendor whose moat is that the customer cannot leave does not have a moat. It has a hostage.

When to stop sending engineers

The model has an endpoint, and companies that forget this are the ones Gartner is describing.

Every deployment should move the configuration boundary outward. Every generalized pattern should mean the next customer needs less of an engineer. The endpoint is a product a customer can deploy themselves, or with their own AI engineer, from the configuration surface. Sierra's move of workflow building into a no-code studio is this. Airbus distributing the FDE function across its own customer engineers, per Meurer, is this from the buyer's side.

When you reach it, the FDE headcount per customer falls toward zero and the margin recovers to software. That was the plan. A company that reaches year four with the same FDE ratio it had in year one has not been running a forward deployed model. It has been running a services firm and calling it product.

The signal to watch is FDE hours per deployment, quarter over quarter, for the same class of customer. Falling means the loop is closing. Flat means it is not, and the fix is in the product, not in hiring more engineers.

Start this week

Pull the FDE hours, or implementation hours if that is what you call them, for your last four deployments of roughly the same size, in order. Draw the line.

If it slopes down, the loop is closing and the margin will follow. If it is flat, you have the cost structure of the model without the compounding, and the next chapter on building the team will not fix it. Only the product will.

Sources: Natalie Meurer, The Dirty Secret of Forward Deployed Engineering, AI Engineer 2026 · Plank, What Is a Forward-Deployed Engineer (revenue per employee, lifetime cost share, Gartner expectation) · Andrew Ng on forward deployed engineers and optionality · Falk Gottlob, The Sierra Playbook (Sacra on implementation intensity)