What’s a Forward Deployed Engineer?

A SaaS product’s real test begins when it meets the customer’s actual environment: messier data than expected, an important workflow hidden in a spreadsheet, an old integration that doesn’t behave the way its documentation claims, and users who’ve built their own rules and workarounds that never made it into the original requirements.

This is the gap that a forward deployed engineer (FDE), sometimes called a forward-deployed software engineer, is hired to close.

Here’s the shape of it: a company buys an enterprise software product, and the product company sends in an FDE to get it working inside the customer’s organization. The starting point is a standard product, but the deployment has to account for the organization’s real data, systems, workflows, and operational constraints.

The FDE is typically on the product company’s payroll, but spends their days working across both organizations. They know the product deeply enough to adapt it in production, while also working with core product engineers when a problem requires changes to the platform itself. On the customer side, they work with engineers, users, and domain experts who can explain why the business operates the way it does. One of the real values of the role is that the FDE doesn’t stop at identifying a problem. Because they write production code, they can act on what they discover rather than passing every issue back through several teams.

Think of the FDE as a tech tailor: you bring in a ready-made outfit, so nobody’s sewing from scratch, but the alterations are significant enough that what comes out the other side fits your exact figure and style.

Depending on what they find, that “tailoring” might mean data pipelines, API integrations, internal applications, evaluation systems, access controls, or AI agents. In practice, the work could involve setting up infrastructure on AWS, writing scripts to connect APIs, or building and deploying a RAG pipeline within the customer’s existing systems. It can take months, sometimes years, because the problem is rarely one missing integration – it’s usually the accumulated effect of how the organization’s systems, processes, and exceptions have developed over time.

FDEs are technically strong enough to move across the stack, comfortable making progress without a complete specification, and practical enough to build what’s needed rather than what looks most elegant on an architecture diagram. They might spend the morning speaking with users, the afternoon tracing inconsistent records through a data pipeline, and the next day changing the design because they’ve discovered that two departments mean different things when they use the same field.

How the FDE model got started

The forward deployed engineering model was pioneered by Palantir Technologies, whose early customers included US intelligence and law-enforcement agencies such as the CIA, NSA, and FBI.

These organizations were dealing with huge amounts of relevant data scattered across separate systems, which they couldn’t simply hand over to an outside vendor along with a full explanation of how everything worked. Even if they could, the work itself changed so quickly that a carefully prepared set of requirements could be out of date before the product ever shipped.

A conventional product team could interview analysts, document their needs, and build from outside the organization, but it had no way to see how the data, security restrictions, legacy systems, institutional relationships, and day-to-day decisions interacted in practice. So, the software could satisfy every requirement on paper and still not survive contact with how analysts actually worked.

Palantir’s fix was to put engineers inside the customer’s environment. Instead of asking the agency to describe its complexity in advance, the engineers went and found it themselves, building against the real data and real constraints as they encountered them.

Palantir made the division of responsibility quite explicit. Its core software engineers, known internally as Devs, belonged to Product Development and owned individual components of Foundry and Gotham, Palantir’s software platforms for working with organizational data and supporting operational decisions. Their job was to make decisions and write code that could serve many customers. FDEs, also known as Deltas, sat within Business Development and focused on the technical outcome of one customer deployment. Palantir’s shorthand was “one capability, many customers” for a Dev and “one customer, many capabilities” for a Delta.

That didn’t mean the Delta was cut off from the product itself. If a missing feature or bug stood between the customer and a successful deployment, the FDE could contribute code to the platform, although larger changes had to be coordinated with the product team and considered against its wider roadmap.

An analysis of Palantir’s model describes this as moving product discovery inside the institution and notes that, by 2016, Palantir employed more FDEs than traditional software engineers. That tells you how the company viewed deployment: not as a secondary service performed after the product had been built, but as part of how Palantir discovered what the product needed to be in the first place.

How FDE work differs from custom software development

At the level of one customer, forward deployed engineering can look like custom development, but in Palantir’s model it sat within a wider product loop: the engineer wrote code for problems unique to one organization, while recurring solutions could still find their way back into the platform.

Say an FDE builds a workaround for an undocumented API. On its own, that’s a one-off fix. But if several deployments keep hitting variations of the same integration problem, the company can turn it into a reusable connector – the same way a one-off pipeline for catching unknown data fields, a permissions pattern, an evaluation framework, or a monitoring component can graduate into something the whole product uses.

The Palantir analysis calls this field-driven productization: field teams solve immediate problems under real conditions, while the core product team watches across deployments for the patterns that repeat. What starts as a scrappy fix for one customer becomes a reusable capability that makes the next deployment faster and the core product stronger.

There’s a second piece to making this sustainable: the engagement has to be designed so the customer gets more self-sufficient over time, not more dependent on the FDE. As the system stabilizes, the FDE works alongside the client’s engineers, documents the architecture and operational procedures, and gradually hands over responsibility. The client’s team should eventually be able to operate, troubleshoot, and extend the customer-specific components without relying on the product company for every change.

This also helps explain why Palantir didn’t consider its Deltas to be consultants, even though the roles can look similar from the outside. Both work closely with customers and try to improve how an organization operates, but Palantir described consultants as generally delivering an analysis, recommendation, or one-time solution, while its FDEs deployed an existing software product and did the engineering needed to create a system the customer could keep using and improving. It isn’t an absolute boundary, since consultancies can also build long-term systems and reuse what they learn. The more useful distinction is that the FDE remains responsible for making an existing product work in production, rather than stopping at analysis or recommendations. In Palantir’s original model, there was a second distinction too: recurring lessons from deployments could shape the wider platform.

Of course, this doesn’t usually come cheap. From the customer’s side, the service needs to produce enough operational value to justify the cost. From the product company’s side, dedicating experienced engineers to individual deployments is easier to justify when at least some of what they learn or build can be reused elsewhere.

Why enterprise AI has brought the role back into focus

AI products have made the deployment gap especially visible, because access to a capable model doesn’t hand you a production system. You still need the right customer data, permissions, integrations, evaluations, monitoring, exception handling, and a place within an existing workflow – and much of that can’t be defined completely until engineers begin working with the organization’s real users and systems.

That helps explain the rapid rise in demand for FDEs: an independent analysis of 1,000 FDE job advertisements found 1,165% more postings from January through October 2025 than during the same period in 2024, while 37% of the postings in the same dataset mentioned AI or machine-learning deployment, 32% mentioned systems or API integration, and 55% mentioned direct customer work.

Not every company means the same thing by the title, though: the analysis classified 60% of the roles as “builder” FDEs, 30% as closer to sales or solutions engineering, and 10% as internal commercial tooling. In practice, a solutions engineer will usually prove that the product works on a curated set of examples to help close a sale, while a builder FDE stays after the sale and makes it work with the customer’s actual production data. Builder roles generally expected 70 to 90% of an engineer’s time coding – so it’s worth looking past the job title and asking whether the person will own production engineering.

The title has now moved well beyond Palantir. AWS says it has formed a new FDE team to embed engineers and scientists inside strategic enterprise customers, while OpenAI advertises FDE positions across North America, Europe, Asia, Australia, and the Middle East, and Anthropic lists FDE roles in the US and Europe. When several companies developing AI products and infrastructure are hiring for a similar role at the same time, it suggests that the title isn’t simply one employer’s terminology, but a response to the wider effort to move AI from demos into production.

As the FDE title has spread to model providers, it has come to cover a broader range of deployment work. A Palantir Delta starts with the company’s existing enterprise software platform and adapts it to one customer’s operations. At a model provider such as OpenAI, the starting point may instead be a set of models and APIs, so the FDE builds the surrounding production system: integrations, agents, evaluations, monitoring, permissions, and the workflow through which people will use it. OpenAI describes its FDE team as sitting between customer delivery and core platform development, with engineers taking deployments from discovery and system design through production rollout while feeding what they learn back into both product and model roadmaps.

Although the classic FDE model puts the engineer on the product company’s payroll, the capability itself isn’t tied to a single employment model. A product company can build it internally or bring in an experienced engineer with the right specialization through an external partner using a model like team augmentation, provided that person receives the access, continuity, and decision-making scope the role requires.

However the role is staffed, its purpose remains much the same: closing the distance between what a product can do and what the customer needs it to do in practice.