An FDE costs about $400,000 a year, so the model only scales if each deployment makes the next one cheaper
AI companies have committed about $10bn in 12 months to building FDE teams. Whether the model survives depends less on how many people they hire than on what those people leave behind.
In brief
- Labs pay $350,000–$550,000 for a senior FDE, which raises the question of whether scaling the model tenfold breaks the economics.
- Without reuse, FDE headcount grows linearly with customers and margins slide towards those of a services firm.
- The most valuable FDE is the one who extracts the reusable half of the work and puts it into the core product.
Hypothetical illustration: both start at 10 customers and grow to 100. What separates them is whether field work flows back into the product.
Graphic: FDE Times
Leading AI labs are paying between $350,000 and $550,000 for a senior FDE, according to investor Tom Tunguz. At the same time, he estimates that AI companies have committed about $10bn in just 12 months to building forward-deployed engineering teams.
At roughly $400,000 per FDE per year, Tunguz asks a blunt question: does scaling this model tenfold break the very economics that made it work? The answer does not lie in how many more people get hired. It lies in whether each deployment makes the next one cheaper.
For a developer hoping to move into FDE work, this is not someone else’s finance problem. It determines which kind of FDE gets paid well and kept on when the market sobers up: the one who solves a problem for a single customer, or the one who turns that solution into something the whole company can reuse.
The straight line is software’s enemy
Valletta Software states the problem neatly: deployment headcount grows linearly with the number of customers, unless each deployment makes the next one cheaper. In other words, the FDE model is structurally expensive. Not because salaries are high, but because the cost recurs with every new customer.
Picture a company with 10 enterprise customers, each needing its own FDE team. At 100 customers, if everything is still built by hand from scratch, the company needs ten times the people. At that point it is no longer a software company but a consultancy with a product attached.
That is why the Inside Software newsletter stresses that FDE only makes sense when it protects software-style margins rather than drifting towards services-style margins. The same source notes that FDE teams can grow to about 8 people on large projects.
That figure points to a practical limit: you cannot pour unlimited people into one customer, so growth across many customers has to come from somewhere else.
Four answers to the same problem
Palantir chose to accept the cost and call it something else. As Tunguz describes it, at Palantir the FDE is not a services layer but the core product itself. Inside Software cites a figure of FDEs making up about 20% of the company’s workforce, though other sources give a lower share.
Valletta Software offers a different formula: the model works as a path to scale when the reusable half of field work is fed back into the core product. Here the FDE acts as a scout for the product team.
Every connector, every data pipeline, every evaluation suite written for customer A has to face one question: does customer B need this too?
Constellation Research takes the argument to its conclusion. It argues that the winning enterprise vendors will take what FDEs learn and embed it into the product, to the point where customers no longer need FDEs at all. In this view, FDEs exist because today’s AI products are still immature.
Meanwhile, services firms are joining in. The CEO of Infosys has said publicly that the company is expanding its team of forward deployed engineers. For a services firm, linear growth in headcount is not a flaw; it is the business model.
But that is exactly the line Inside Software warns software companies not to cross.
| Scaling approach | Proposed or followed by | What the FDE is measured on | Main risk |
|---|---|---|---|
| FDE as the product | Palantir | Value created at each customer | High share of FDEs in the company, high cost |
| Feed the reusable half into the product | Formula described by Valletta Software | How much cheaper each deployment makes the next | Product team cannot absorb field feedback |
| Productise until FDEs are no longer needed | Constellation’s scenario | How much manual work becomes features | FDE role shrinks as the product matures |
| Add headcount | Services firms such as Infosys | Hours and projects delivered | Services-style margins |
Apart from the pure services model, all three remaining approaches bet on one mechanism: field work must flow back into the product. They differ only in how fast it flows and in how much of the FDE role remains once the flow is complete.
Every shortcut in the field has a price
Both Valletta’s formula and Constellation’s scenario implicitly demand the same skill: the ability to look at a messy deployment and separate what only this customer needs from the patterns that will recur at the next one.
The skill is harder than it looks. In the field, the pressure is to deliver before the deadline, so the fastest route is always to write custom code, hard-code configuration and fix data by hand. Each such shortcut is reasonable that week; added together, they are what drags the company back onto the straight line.
So if a company pays $400,000 for an FDE, the money is only worth it if that person leaves behind something bigger than one satisfied customer. Even in Constellation’s scenario, when the product matures and fewer FDEs are needed, the people who did the productising are the ones who understand the product and the customers most deeply.
Where should Vietnamese developers place their bets?
Many Vietnamese developers work at outsourcing companies, which means they live inside a services model priced by headcount. That is not a weakness: they are used to sitting alongside customers, reading unfamiliar systems and delivering under pressure. What is often missing is the habit of asking which part of a project should become product.
Show that habit in your CV. Instead of “deployed a system for a banking client”, write which reusable component you extracted, such as a connector, an evaluation test suite or a deployment template, and how much time it saved on later projects.
Writing it this way shows recruiters that you understand the margin problem, rather than leaving them to infer it from a list of projects.
When reading a job description or going to an interview, notice where the FDE sits on the org chart. If the role is tied to the product team and there is a clear process for feeding field feedback into the roadmap, that is a model trying to bend the straight line.
If the role is measured only by the number of projects delivered, you are applying for a services job under a new name.
The question worth watching is not whether the industry still needs FDEs, but how much each FDE leaves in the product after leaving the customer. Be the person who can answer that question with numbers.