Forward deployed engineering helps sell a technically complex platform to buyers who cannot build with it themselves.
2
An FDE team must build on reusable platform primitives, or it becomes a custom development shop with unmanageable maintenance costs.
3
The model fits only when a company has both a non-technical buyer for a complex product and a platform that engineers can extend.
Summary
Kevin Bai explains forward deployed engineering through Palantir's use of Foundry. Foundry centralizes an organization's data, creates a shared ontology, and lets customers build applications, but many Fortune 500 buyers lack the engineering depth to turn that platform into business results. Palantir therefore sends engineers who understand the customer's operations and build a solution on the platform. The customer pays for an outcome rather than only software or engineering time. Bai distinguishes this from a dev shop. FDE engineers assemble reusable primitives instead of writing every customer solution from scratch. He gives two tests for starting the function: whether the company must sell a complex product to a non-technical buyer, and whether it has, or will build, a platform for reuse. He argues that AI makes software more customizable, so more companies may face the same implementation problem. In the Q&A, he discusses primitive granularity, collaboration, platform boundaries, and the FDE profile.
Palantir sells a platform together with the engineering needed to use it
Palantir's Foundry centralizes an organization's data, creates an ontology with shared business entities, and lets companies build applications. A buyer may understand the business value without knowing how to turn the platform into an operating solution. Customers also face the cost of training people before they can use what they bought. Palantir combines software with engineers who learn the customer's business, build on Foundry, and deliver a result. Bai says an industry leader cares about outcomes such as more shelf placement or higher sales throughput, not how the underlying data is organized.
FDE is for technically complex products sold to non-technical buyers
Bai places FDE at the intersection of the product and the buyer. A technical product sold to CTOs or engineers can usually be adopted by its users. A less technical, configurable product can be sold to a non-technical buyer without engineers building on it. FDE is needed in the unusual case where a company sells a very technical platform to a non-technical organization. A Fortune 500 oil and gas company may not have the engineering depth to build applications on the platform, even though it has valuable operational problems to solve.
Loaned engineers let enterprise customers reach outcomes they cannot implement alone
Palantir's engineers work closely with enterprise customers instead of leaving them to recruit, manage, and retain the talent needed to use Foundry. Bai compares the relationship to a fine-dining waiter who understands the customer's needs and works out how to solve the problem. This approach helped Palantir sell to the global Fortune 500. Bai cites average contract values from public SaaS companies: Palantir at $4 million, ServiceNow at $1.2 million, and Workday at $600,000, with no other public SaaS company reaching $500,000 when he last checked.
An FDE team scales design partnerships through a reusable platform
Bai describes FDE as the enterprise-scale version of a startup design partnership. The customer supplies context about its problem while the team builds a solution. This model fails when every customer receives a completely bespoke codebase. In that case, the company has a dev shop, not an FDE function. FDE engineers should assemble applications, workflows, and solutions from shared primitives on top of a platform. Without that base, the company repeatedly reinvents the wheel, accumulates maintenance costs, and makes the code difficult for engineers to support.
Companies should test their need for FDE before copying the model
Bai's first question is whether the company needs an FDE function. The test is whether it has to take a technically complicated product to a non-technical buyer. If it does not, a developer engagement team may fit a technical go-to-market motion, while sales-led growth may fit traditional SaaS. The second question is whether the company has a platform, or is willing to build one, with shared primitives that FDE engineers can use. Bai warns that even a strong platform creates maintenance work, so sending engineers to make money without a reusable foundation creates serious operational problems.
AI makes customer-specific software easier and spreads the implementation problem
Since Palantir entered the market, artificial intelligence has made code and sophisticated customizable software easier to build. Bai's hypothesis is that the change is in the software business itself, rather than companies simply deciding to copy Palantir's FDE motion. If nearly every platform becomes agentic and customizable, customers may have less understanding of what a product can do or how to implement it. Leaving product success entirely to the customer's implementation ability becomes harder as companies sell upmarket or expand into new industries and functions.
Reusable primitives should match the breadth and needs of the customer base
In the Q&A, Bai says primitive granularity depends on the market. In some industries, a platform can provide a heavily built application and let the customer customize the remaining part. Other use cases need granular configuration and tooling. He uses AWS as an example of a broad platform that provides shared primitives such as DynamoDB, so customers do not have to invent and operate a database from scratch. The right level depends on how broadly the platform must serve customers and how much variation their use cases require.
Generalizable customer work should move into the platform
Bai says work that is bespoke and unique to one customer can remain on the forward deployed side. Anything that can be generalized should move into the platform over time. Early FDE teams may have few primitives, and that is acceptable because customer work can reveal which product capabilities would help future deployments. He also encourages multiple FDEs to work together so one person is not the only holder of customer knowledge. His description of the role is simple: an FDE is a customer-facing software engineer.
"If you were to implement an FTE function where each FTE is building entirely from scratch, my friends, you do not have an FTE function. You have a dev shop."08:32
Who should watch
You are considering a forward deployed engineering team and need a test for whether the model fits your product and buyer.
Your enterprise product needs customer implementation work, but you want to avoid turning every deployment into a separate codebase.
You lead platform or go-to-market work and want a practical view of how reusable primitives should shape customer engineering.
