Your Pricing Model Decides What Your FDE Team Is For
Everyone is selling outcomes. Who is paying for the build?
When AWS announced its forward deployed engineering organisation at the end of June, most of the coverage went to the billion dollars. The detail worth reading twice was further down. Pods of five or six engineers, forty-five day cycles, priced on fixed outcomes rather than billable hours.
Fixed outcomes, committed to before the work starts, on a timeline that leaves little room for the scope being wrong. That is a bold thing to offer, and the interesting question is why a company would be comfortable doing it. The answer depends entirely on what kind of business is underneath.
There are four ways the deployment work gets paid for. Experienced FDE leaders will have seen several of them, and probably argued about all of them. What I want to do here is lay them out side by side, because each one gives the FDE team a different job, and the differences only become visible when you look at where the money actually moves.
1. The meter pays
The first model belongs to the labs and the hyperscalers, and it is the one being discussed most loudly right now.
If your core business is metered consumption, the deployment is not a revenue line at all. It is acquisition cost. Anthropic has moved enterprise contracts off flat seat pricing to a lower headline seat price with token consumption billed at API rates on top. Once that is the shape of the business, the question of what to charge for the deployment stops being interesting. The deployment exists to install the meter.
You can see this in the AWS architecture itself, which puts a semantic layer inside the customer’s own AWS account and feeds a versioned knowledge graph that agents reason over. That is not a deliverable. It is a tap. Microsoft’s version, a two-platform structure designed to compound the customer’s proprietary data and workflows over time, is the same idea in different language.
Which is why offering fixed-outcome pricing costs them almost nothing. If the outcome lands, everybody is happy. If it misses, the semantic layer is still sitting in the customer’s account, the integrations are still wired, and the consumption still runs. The outcome fee is a rounding error against what flows through afterwards. It looks like risk transfer and it is closer to a promotional offer.
There is a smaller version of this model that shows up well below hyperscaler scale. A vendor that sells usage credits builds the solution at no charge, and in return asks the customer to commit to a consumption level up front. Fifty thousand in credits, say, purchased or contractually committed before the build begins. The deployment is still free on paper, but the customer has underwritten it. It is a sensible structure for both sides when it is priced honestly, and a quiet trap when the committed consumption was sized to fund the build rather than to match what the customer will actually use.
None of this is a criticism. It is a rational way to behave when you sell a meter. But if you run an FDE team inside a company that does not sell a meter, and you find yourself under pressure to match those commercial terms, it is worth knowing that you are being compared against a business that is not taking the same risk you would be.
2. The customer pays, and can see it
The second model is the explicit one, and it is less common than you would expect.
Sierra prices per successful resolution, at around a dollar fifty per case. Alongside that sit setup fees running between fifty and two hundred thousand dollars depending on integration complexity, with deployments taking three to seven months. The per-resolution pricing carries the narrative. The setup fee is where the deployment cost is actually recovered.
This structure has a lot going for it. It puts the build in front of the buyer as a real thing with a real cost, which means the conversation about scope happens while both parties are still holding a pen rather than six weeks into delivery. It also creates a clean internal boundary. The team doing the build is funded by a specific line on a specific contract, and you can tell whether the funding covers the work. When the assessment is wrong, it is visibly wrong, and the correction is a commercial conversation rather than a silent write-off.
The catch is that it requires a buyer sophisticated enough not to flinch at a six-figure setup fee, and a market position strong enough to ask for one. Plenty of companies would like to charge for implementation and cannot, because the competitor down the road is not charging for it.
3. Nobody pays, because there is barely a build
The third model is the one every product team says it is heading towards.
Fin charges ninety-nine cents per outcome with no integration fee, no setup fee, and no platform charge when it runs on an existing helpdesk. It can do that because it deploys in days rather than months. There is no deployment cost to recover.
This is the honest end state of productisation, and it is a real achievement rather than a trick. But notice what it implies. The pricing model is downstream of how much deployment the product needs. When someone tells you their pricing is simpler than yours, they are usually telling you something about their product surface rather than their commercial sophistication. And the categories where this works tend to have a narrow, well-bounded job to do. It has not yet happened in the messy middle of enterprise operations, and I am not convinced it is close.
4. The customer pays, and never sees it
Then there is the fourth model, which is where a large share of mid-market deployment work actually happens.
The shape is familiar. An FDE assesses how complex the solution is likely to be, that assessment maps to a tier, and the deal is quoted as an annual subscription in that band. Twenty thousand, forty, eighty, a hundred, invoiced monthly from the month after signature. There is no implementation line item. The vendor builds the thing, gets it running, and recovers the build across the term of the contract. One year locked, rolling into the next unless somebody cancels.
From the customer’s side this is clean. They see software pricing. They assume the number reflects the product.
From the vendor’s side, year one is underwater. You are spending the most expensive people in the company on a build you are not charging for, against a subscription that will take most of the contract term to get back to level. The margin is not in year one. It is in the renewal.
The bet hiding inside that structure is this. The model makes sense if you believe your solution is genuinely good enough to replace a person, or several people, at a lower cost than employing them. If that is true, the customer has no reason to ever switch it off. Cancelling means rehiring the work back. The renewal is not something you fight for each year, it is the default state, and the long recovery stops being risky and starts being patient. The whole model is a confidence statement about the product, dressed up as a pricing decision.
It also changes what the FDE team is for. If the money is in the renewal, then adoption is not a soft outcome that makes everyone feel good about the project. It is the entire commercial case. A deployment that technically works and goes unused does not just cost some goodwill. It costs the year you already spent. The slow business of getting a sceptical operator to route real work through the system stops being the unglamorous tail of the project and becomes the part that determines whether the account was ever worth signing.
Tanay Padhi framed the underlying economics well when we spoke: total cost of ownership for enterprise systems has always run at something like sixty to seventy per cent services and thirty per cent licence, and the companies now raising at software multiples are targeting somewhere between one and one and a half million dollars of revenue per FDE. The tiered subscription model does not make that services cost disappear. It moves it out of the invoice and into the margin, where it is harder to see and harder to argue about.
The price is set at the moment of least information
Whichever of the four you are in, they all rest on the same fragile thing.
The tier, the setup fee, the outcome definition, the consumption commitment. All of them are fixed at contract time, from a complexity assessment made before anyone has been inside the process. And the outcome has to be written into the contract as strictly as possible, because without a defined outcome nobody can tell when the work is finished. So you write it as tightly as you can, using what you know at the time.
What you know at the time is what the champion described. The operators, the people whose daily work actually determines how complex the build turns out to be, are usually not in the room yet. So the price and the definition are both set at the point of least information in the entire engagement, and everything that follows is either absorbing the difference or going back to the customer.
Going back is not fatal. When an assessment turns out wrong, you have the conversation, you reprice or you find the upsell, and sometimes that lands well because by then you have something working to show. But it costs credibility at exactly the moment you are asking for trust, and you only get to do it so many times with the same customer.
Stage changes what you are allowed to do
One thing I would tell anyone building an FDE team early: you have more room than you will ever have again, and you should use it deliberately rather than accidentally.
At a small company you care about revenue more than you care about the composition of revenue. You can take a build that was almost entirely custom and call it product licence, because there is no one to tell you otherwise and because you honestly intend to productise it later. That flexibility is real and it is useful. It lets you fund discovery out of customer money instead of investor money, which is a much better trade than it sounds.
The trouble is that it expires. At some point the revenue mix starts getting looked at properly, and the custom work you were booking as licence has to be recognised for what it is. Palantir spent years walking professional services down from around a quarter of revenue to something closer to a fifth, and built the entire bootcamp motion to reduce how much deployment each new customer needs. That is what deliberate looks like.
The moment you can no longer blur the line is a stage marker in itself, and it is worth knowing which side of it you are on before somebody else tells you.
There is one variable I have deliberately left out, which is who owns the budget on the customer side. Engineering-owned, go-to-market-owned and customer-success-owned deals do not price, scope or renew the same way, and I do not yet have a clean framework for why. What I am confident about is this. The commercial model your company runs was picked by somebody, under constraints that made sense at the time, and most FDE teams inherit it without ever being told what it commits them to. Finding out early is cheaper than finding out at renewal.