FDE Is Not a Job Title, It's a Business Model: Palantir's $4M ACV Growth Strategy

While everyone debates “should I hire an FDE?”, Kevin Bai suggests a more useful question: does your business model need forward deployed engineering?

Kevin is on the applied AI team at Anthropic. Before that he built Rippling’s FDE function from scratch—he was the first hire, and the team grew to about 25 in a year. Even earlier, he worked at Palantir. The numbers he shared in a public talk are more persuasive than any job description: measured by average contract value (ACV) among public SaaS companies in the Fortune 500, Palantir ranks first at roughly $4 million. ServiceNow is second at about $1.2 million, Workday third at around $600K, and after that, no public SaaS company even crosses $500K.

That gap is not a small edge. It points to a larger conclusion: FDE is not a role—it is a growth strategy. This article breaks down what it is, when you need it, what makes it work, and why AI makes it the default.

First, what is Palantir actually selling

Palantir’s core product, Foundry, is an application-building platform: it centralizes scattered enterprise data, builds an ontology (turning scattered tables into a single source-of-truth “proper noun”), and lets teams build applications on top. It sounds great—until you hit the sales problem. An industry leader listens and says, “You’ve organized my data. What does that do for my actual business?”

If you sell only technology, the customer must do three things: pay for the platform, train their people to use it, and only then build something. That hidden tax is a huge reason technical products stall.

Palantir’s answer: sell neither software nor engineer-hours—sell the outcome. Send smart people to the customer site, understand their business, build solutions on Foundry, and the customer receives business results—more shelf placement, higher sales throughput. How the data is organized is an implementation detail the customer should never have to care about.

When you actually need FDE: a four-quadrant framework

Kevin uses a Punnett square with two variables: how complex is the product and how technical is the buyer.

Product complexity	Buyer technicality	Typical example	FDE needed?
High	High	GitHub, Datadog	No
Low	Low	Jira, Slack	No
Low	High	dev tools sold to engineers	No
High	Low	Palantir’s Foundry	Yes

Only the “complex product × non-technical buyer” quadrant needs FDE. Here is why:

• Selling to CTOs/CIOs (technical buyers), they can absorb complexity themselves—no need to send people.
• Selling a simple, configurable product to non-technical buyers (Jira, Slack)—also no.
• Only “complex product × non-technical buyer” is the hard case: the customer lacks engineering depth. An oil-and-gas Fortune 500 company moves hydrocarbons through pipelines, not data. They cannot and should not build the team that would deploy a Foundry application themselves.

In that case you stop hoping the customer learns your platform. Instead you “loan” them engineers: no hiring, managing, or retaining on their side. The engineers work side-by-side, solve problems, and deliver outcomes.

FDE is not outsourcing: platform primitives are the key

Many people object immediately: customizing for every customer is just software outsourcing. Code turns to spaghetti, engineers quit, maintenance costs eat the margin.

Kevin’s reply is blunt: if every FDE writes code from scratch, you don’t have an FDE function—you have a dev shop. What makes FDE sustainable is that FDEs always build on top of a platform. They never reinvent the wheel.

The platform provides primitives: data models, components, workflow templates. The FDE’s job is to assemble them into applications valuable to a customer—60% existing building blocks, 40% customized assembly. AWS is the extreme version: it gives you DynamoDB so you don’t invent the database from scratch.

This also explains how Palantir sustains high ACV with a few thousand employees: every project feeds reusable primitives back into the platform, so the next project gets faster and cheaper. Build from scratch every time and the margin dies as you scale.

Decision framework: does your business need FDE?

Kevin offers a two-step self-check:

Step one: must I sell something technically complex to a non-technical buyer? Note: must, not want. If you have a technical go-to-market (selling to engineers), DevRel is the better answer. If you run traditional SaaS, sales-led growth (SLG) works. Only the “complex product × non-technical buyer” quadrant justifies FDE.

Step two: do I have a platform—or am I willing to invest in building one? No platform means no primitives, and FDE degrades into outsourcing. This step decides whether FDE is a growth engine or a cost black hole.

Ask these two questions before you ask “should I hire an FDE?”

Why AI turns FDE from a Palantir quirk into the default

Kevin offers a judgment worth sitting with: what changed is not that the world suddenly discovered Palantir’s FDE playbook. What changed is how the software industry does business.

In 2026, nearly every platform is agentic, and nearly every platform is customizable. That means a growing number of companies are drifting from “tools for engineers” toward “complex systems the customer has no idea how to use.” AI makes it extremely cheap to build sophisticated custom software for every customer—everyone is building agent-for-X (insurance, legal, finance)—but customer implementation ability has not kept pace.

The result: only Palantir, the strange data-platform company, used to need FDE. Now almost any company selling AI products hits the same wall—success depends on the customer, and the customer cannot use it.

This echoes what this site keeps saying: the value of AI adoption must be verified layer by layer, along the chain of “task capability → process outcomes → customer experience → revenue and profit.” The FDE is the key person on that verification chain—he does not just build the system, he watches it enter real work.

What a good FDE looks like

Kevin’s definition is refreshingly simple: an FDE is a software engineer who can face a customer. You would hire them as an engineer by engineering standards, and you trust them in front of a customer in some capacity. Industry knowledge, communication, project management—all nice-to-haves, not entry requirements.

One organizational principle worth noting: multiple FDEs should work the same project to avoid single points of failure. One person holding all the context, then going on vacation and stalling the project, is the classic custom-delivery failure.

Evidence and limits

• This article is based on Kevin Bai’s public talk (AI Engineer channel, 2026). The ACV figures and Palantir strategy come from that talk; no non-public client information is repeated.
• The four-quadrant framework and platform-primitives idea are decision frameworks, not the only correct organizational form. DevRel, SLG, and FDE each fit different situations.
• For small teams without a platform and without plans to build one, the FDE model likely does not hold—standardize the product first, before hiring deployed engineers.
• FDE success requires the platform to keep accumulating reusable assets. Send people without building a platform, and scale just brings you closer to outsourcing.

To think through how enterprise AI actually lands, continue with FDE Is Not On-Site Firefighting, or see another service model in why vertical AI services create value. For how organizations absorb AI-driven change, see the organization and service growth topic.