When Does an Enterprise Truly Need FDEs? Before Building an FDE Team, Pass These Two Gates First...

In enterprise software, one problem keeps recurring: a vendor delivers a powerful underlying platform, but even after paying for it, the customer still does not know how to turn that capability into business results. Palantir Foundry, for example, can centralize data, build an ontology, turn raw data into business objects such as warehouses, and support applications built on top. Yet an enterprise leader will still ask, "What does this actually do for my business?" When a vendor sells technology alone, it leaves the customer responsible for understanding the problem, learning the platform, and building the applications.

A Forward Deployed Engineer (FDE) is meant to bridge that gap between platform capability and business results. Kevin Bai, now at Anthropic, structured his "FDE 101" talk at AI Engineer World's Fair around three questions: what an FDE is, why enterprises need the role, and why he expects it to spread in the AI era. He previously worked in a related role at Palantir and joined Rippling's FDE team as its first member, helping it grow to about 25 people in one year. The most useful part of his framework is that it offers two concrete tests: which combinations of product and buyer genuinely need FDEs, and what platform foundation prevents an FDE team from turning into a dev shop.

Customers Should Buy Outcomes, Not a Platform They Still Have to Learn

When a vendor sells only a platform, the customer must pay for the software and then invest additional staff time in learning it before useful applications can be built. FDE combines the platform with engineering services: engineers first understand the customer's business, then assemble a solution on top of the platform. The customer is buying neither software alone nor simply a person's billable hours, but a working business outcome. In a conventional model, the vendor sells the platform and leaves learning and implementation to the customer. An FDE model includes understanding the business, building the solution on the platform, and delivering the outcome as part of what the customer purchases. The FDE is therefore not a remedial implementation specialist brought in after the sale; the role is part of how the product is sold and delivered.

Consider a consumer packaged goods (CPG) company. Its business team cares whether products reach more shelves and whether sales increase; how the data is organized is an implementation detail. The FDE's job is to understand those business requirements and build the solution using capabilities the platform already provides.

This way of working is familiar from the early stages of a B2B startup, when neither the team nor the customer may fully understand what the final product should be or what the customer is really buying. The customer supplies a real problem, while the company contributes time, resources, and technology to build a solution together. Through that process, the team discovers the product shape customers are actually willing to pay for—product-market fit (PMF). FDE can be understood as extending this kind of design partnership into long-term enterprise delivery, rather than limiting it to a startup's first 18 months.

What an ACV Chart Can and Cannot Show

Annual contract value (ACV) is the amount one customer pays a vendor in a year. These figures do not establish a universal spending threshold. They show how much Palantir's revenue per customer differs from that of other large enterprise software companies.

The estimate chart lists Palantir at about $4.0 million in ACV per customer, ServiceNow at about $1.2 million, Workday at about $800,000, Snowflake at about $322,000, Salesforce at about $252,000, and Microsoft Azure at about $214,000. Workday also carries a second, qualified estimate of roughly $600,000.

The figures do not share a single cut-off date or complete calculation method. Some were derived by dividing revenue by a disclosed customer count; where a company did not publish complete data, the estimate used a related business segment or a third-party figure. The chart therefore cannot serve as a strictly comparable financial ranking, and it does not prove that FDE alone causes Palantir's high ACV. At most, it suggests that combining a platform with engineering delivery gives Palantir substantially more revenue per customer than a conventional SaaS company.

The Real Decision Axes: How Technical Is the Product, and Can the Buyer Implement It?

Not every enterprise software product needs FDEs. The decision depends on both how difficult the product is to implement and whether the customer team can implement it independently. The important question is not whether the executive who signs the contract is technical. It is whether the people responsible for building and using the solution can turn the platform into a working business system.

A technical product sold to a technical buyer does not need FDEs. GitHub and Datadog may be complex, but their users are software engineers who can absorb and use that complexity themselves.

A configurable product sold to a non-technical buyer does not need FDEs either. Rippling, Jira, and Slack may also be complex, but they are designed for users to configure, not to develop on top of.

A technical platform sold to a business team without sufficient software-engineering capability is where FDE genuinely fits. Google, Meta, and AI labs have engineering teams that can build the applications they need. A Fortune 500 oil and gas company may not have the same software-engineering capacity. The contrast is easy to picture: an oil and gas company may excel at building physical pipelines without knowing how to build data pipelines. If it implements the platform itself, it must recruit and manage engineers, retain that talent, and train the team on a new platform. FDE provides an engineering team that already understands the platform and can work closely with the customer: first identify the right problem, then build a usable solution.

The value of this matrix is that it prevents misuse. FDE is not a role to add simply because an enterprise customer is large, nor is it a standard feature of every high-ACV product. What matters is whether a real gap exists between product complexity and the buyer's ability to implement it.

The Boundary Between FDE and a Dev Shop Lies Beneath the Platform

An obvious objection is that if every enterprise customer needs customization, the company may end up with dozens of disconnected codebases that no one wants to maintain. That concern is valid. If every FDE starts from scratch, the team is running a dev shop, not the FDE model described here.

If each customer requires a fresh build, every new account adds another independent codebase and more maintenance work. Rebuilding the same functions repeatedly will eventually consume the profit, and engineers may leave before that happens.

The real dividing line is whether the company has a reusable set of shared platform modules, such as data models, application components, or workflows. Customer solutions can be customized, but they cannot begin from a blank project every time.

Suppose the first retail customer wants purchasing staff to receive an automatic alert whenever inventory falls below a safety level. An FDE can build that solution for the first customer. If the second and third customers need the same thing, the team should turn the inventory check, alert, and approval workflow into shared platform modules. The next customer then connects its own data and configures its safety level and approvers instead of paying for another alerting system to be written from scratch. Rules unique to one customer can remain in that customer's solution.

In this model, field projects do more than add maintenance work; they also strengthen the product. If every customer instead has a separate codebase, the same functions are rebuilt repeatedly, and each old project must continue to be maintained by the engineer who created it, then adding customers only increases the burden. The team has effectively become a dev shop.

This also explains why "putting engineers directly on revenue-generating work" may sound attractive but is not, by itself, a sufficient reason to build an FDE team. Maintaining customer solutions remains demanding even with a robust platform. A platform makes that burden manageable; it does not make the burden disappear. Without one, the risk can become existential.

AI Is Making the "Customer Cannot Implement It" Problem More Common

AI makes code easier to write and complex custom software easier to build. The deeper change is that more platforms can act like agents, breaking down and executing tasks on their own, which also gives customers more room to customize. But the more open-ended a product becomes, the less its usage resembles a fixed SaaS feature. Customers may see what the platform can do without knowing which business problem it should solve, how to connect their data, how to configure the workflow, or how to put it in the hands of real users. Making code easier to produce does not automatically make problem definition, solution design, or enterprise implementation easier.

When a software vendor leaves the success or failure of implementation entirely to the customer, the obstacle becomes larger as the vendor serves bigger enterprises, supports more general use cases, or enters new industries.

One hypothesis still needs to be tested: AI is creating the same mismatch for more companies—products are becoming more technical while actual buyers lack the engineering capacity to implement them. This is not yet a proven universal law, and it does not mean that every AI product capable of acting autonomously needs FDEs. The practical question is simpler: after the customer buys the product, how much engineering work remains before it is genuinely usable, and can the customer complete that work independently?

Five Practical Questions That Clarify the Boundaries

Five concrete questions arise when building and operating an FDE team. None has a fixed answer that every company can copy, but together they help a team examine how responsibilities are divided and how its platform is designed.

How much should the platform pre-build, and how much customization should it leave to the customer? The answer depends on the user base and the industry. Some industries might start with an application that is 60% complete and leave the remaining 40% for customer customization; other settings need more basic and flexible tools. The 60/40 split is an example, not a target. AWS offers a useful analogy: an engineering team could buy and maintain servers itself, but usually uses a cloud platform instead; DynamoDB likewise avoids the need to invent a database from scratch. The more varied the users, the more the platform must offer broadly useful building blocks. A narrow industry may allow the platform to pre-build more capabilities shared across that industry. No single ratio applies to every company.

Should more than one FDE be assigned to the same account? A safer approach is to have at least two people share the project context. If one person knows every important detail, the project becomes difficult for anyone else to take over when that person goes on leave or departs, and work may stop.

How should FDEs from different vendors collaborate on the same project? If AWS and Palantir engineers are working on one project, first determine whether the companies are competing for the same work or acting as partners to deliver it together. If they are partners, establish who is responsible for the final delivery and who is supporting it. That resolves only the basic division of responsibility; the parties still need a separate agreement for handling disagreements among vendors.

Where is the boundary between customer-specific and shared platform functionality? Keep functionality needed by only one customer in that customer's solution. Turn functionality repeatedly needed by several customers into shared platform modules. It is normal to have few shared modules early on. Repeated needs found in the field help the product team decide what is most valuable to build next.

Who is suited to FDE work? The basic bar can be concise: the person must meet the company's software-engineering hiring standard and be someone the company trusts to work directly with customers. In short, an FDE is a customer-facing software engineer.

Before Building an FDE Team, Pass Two Gates

Gate One: Is the Customer Merely Unwilling to Implement the Product, or Actually Unable To?

Look at the customer team responsible for turning the product into a usable system, not the executive who signs the contract. Three situations need different responses:

• The customer has a mature engineering team but is unfamiliar with your product. Documentation, developer relations (DevRel), and technical support should usually be the first response; the customer probably does not need an FDE embedded for the long term.
• The customer can implement the product by selecting options, connecting data, and adjusting rules. Sales, customer success, and implementation consultants are usually enough.
• The product requires code, data-model design, or complex workflow construction, while the customer lacks the corresponding engineering team. Only this case passes the first gate.

A simple test is: Without engineers from the vendor, can the customer independently turn the product into a usable system within a reasonable time? If yes, FDE is probably unnecessary. If no, and the obstacle is genuinely a lack of engineering capacity, proceed to the second gate.

Gate Two: Can Work Written for This Customer Be Reused for the Next One?

FDEs can customize solutions, but the company must turn recurring needs into shared modules. Otherwise, every engineer will carry a separate codebase while serving one customer indefinitely, and the team will quickly become a dev shop.

Four signals make this easy to inspect:

• Can most of a new customer's solution be assembled from existing data models, components, and workflows?
• When two customers need similar functionality, does the team turn the common part into a platform capability that every customer can use?
• Can customer-specific rules remain separate from shared modules, so one customer's special requirements do not affect everyone else?
• As the customer base grows, does the next delivery become faster, or does every project still begin from zero?

For example, suppose three customers all need inventory alerts. A healthy approach is to make inventory checks, alerts, and approvals into platform modules, while each customer configures its own safety level and approvers. If all three customers have separate codebases that only their original engineers can maintain, the team has not passed the second gate.

"The platform provides 60%, and the customer customizes 40%" is only an example, not a universal passing score. The real question is whether each completed customer project leaves the platform with another capability the next customer can reuse immediately.

After both gates are passed, the team can decide the more specific operating questions: how many customers one engineer can support, whether two people should share responsibility for an account, and which recurring needs the product team should formally add to the platform. If either gate is missed, hiring FDEs first will turn a product-selection or customer-selection problem into a more expensive engineering-maintenance problem.