Forward Deployed Engineer: What It Is and When Your Business Needs One

Every company that buys serious software knows the gap. The contract is signed, the demo was impressive, and then months pass while the system is configured, integrated, and adapted to how the business actually works. Sometimes it never arrives at all. The demo ran on clean data and a prepared script. Your business runs on messy documents, half-documented workflows, and access rules nobody wrote down.

The forward deployed engineer, usually shortened to FDE, is the role built to close that gap. Instead of building software in a headquarters office and handing it to a customer success team, an FDE goes to work inside the customer's organization: sits with the people who will use the system, sees how the work really happens, and writes the code that makes the software fit. This article explains what the role is, where it came from, what an FDE does day to day, and how to tell whether your business needs one, or a partner who works the same way.

What a forward deployed engineer actually is

A forward-deployed engineer is a software engineer who embeds inside a customer's organization to build, configure, and ship working software on the employer's platform, inside the customer's own data, security rules, and workflows. The job is judged on one question: is the system running in production and doing useful work? The role sits between the vendor's product team and the customer's own IT department, and it belongs fully to neither.

The model was popularized by Palantir around 2009. Palantir's platform was powerful, but customers could not turn it into working systems on their own: the data was messy, the workflows were specific, and the gap between a signed contract and a system in production was where deals stalled. The answer was to send engineers to live inside the customer's world. Palantir still calls these engineers Deltas internally, and splits the work in two: Devs build reusable platform capabilities that serve many customers, while Deltas, the forward-deployed software engineers, take one customer and many capabilities, and make them work together in that customer's environment. A Delta is usually paired with a Deployment Strategist, called an Echo, who owns the mission context, the stakeholders, and adoption, while the Delta owns the technical build.

One misconception is worth clearing up early: an FDE's role goes beyond giving advice. Some consulting engagements end with a recommendation; others include hands-on delivery. An FDE writes production code, debugs systems in production, configures platform behavior, and stays to deliver the agreed outcome. The work looks like ordinary software engineering. The pressure comes from where it happens: on site or on a call with the customer's team, working through real deployment problems together.

What an FDE does day to day

Job postings and firsthand accounts describe the work in three overlapping parts: understanding the problem, building the solution, and making sure it sticks.

The first part is diagnostic. The FDE joins the customer's standups, watches analysts and operators do the work, and finds where the process actually breaks: the data pipeline that fails on real records, the document set that contradicts itself, the approval step that nobody can explain. This is the part a ticket alone rarely captures. Watching a customer struggle with a workflow teaches more than reading about it in a requirements document.

The second part is build. The FDE writes production code, typically in Python, TypeScript, or Java, that connects the employer's platform or AI models to the customer's existing systems. That means data pipelines that pull, clean, and model records from warehouses, ERPs, ticketing systems, and document stores, and retrieval and agent workflows that let models read internal data and take approved actions through customer APIs. Where configuring an existing capability is faster than building from scratch, the FDE configures it. The goal is a working system, not a larger codebase.

The third part is making it stick. The FDE trains the customer's own staff to use and eventually maintain what was built, documents the decisions that matter, and feeds lessons back to the product team so the platform itself improves. An engagement that ends with a system nobody on the customer's side understands is not a finished deployment. It is a dependency waiting for the next breakage.

FDE vs the roles it gets confused with

The title is new to many people, and it gets mixed up with several neighboring roles. The differences matter, because hiring the wrong one is how a deployment stalls.

Read the table as a guide to typical responsibilities. Titles overlap, but an FDE's accountability is a system that works in production for that specific customer, not simply an approved design, a delivered recommendation, or a completed rollout checklist.

Role	Typical focus	How it compares with an FDE
Forward deployed engineer	Adapting and deploying software within a customer's environment	Combines customer discovery, hands-on engineering, and production delivery
Product engineer	Building reusable capabilities for many customers	Usually focuses on the shared product rather than one customer's deployment
Solutions architect	Designing how systems fit together	May also build, but the role often emphasizes architecture and technical guidance
Consultant	Solving a business or technical problem within an agreed scope	Can advise, build, or both; production responsibility depends on the engagement
Implementation engineer	Configuring, integrating, and rolling out a product	Overlaps with FDE work, often within a more established implementation process
In-house engineer	Building and maintaining the company's own systems	Can perform similar work, with ongoing responsibility inside the business

Why the model is spreading now

Long associated with Palantir, the model is now gaining wider attention. It is spreading now because the problem it solves has become the central problem of business AI. Models are easy to demo and hard to deploy. A language model answers a prepared question well. Connecting it to real documents, real permissions, and real workflows, and keeping it correct as those change, is where most AI projects stall. That is deployment work, and it is exactly what an FDE does.

AI labs and enterprise software companies have copied the model. Palantir's FDE teams are the original example, and similar roles now appear at OpenAI, Anthropic, Databricks, Scale AI, Cohere, Ramp, and Rippling, among others. In an October 2026 Microsoft post, Kevin Shatzkamer, Corporate Vice President of Forward Deployed Engineering, wrote that FDE teams there are now augmented with coding assistants and deployment agents, which says something about where the role is heading: the engineer still owns the deployment, and AI tools do more of the routine code. Hiring has followed. Plank's September 2026 hiring census counted 1,333 live FDE roles across 565 companies on 12 September 2026, illustrating how widely the title has spread.

The demand is not about the title. It is about the pattern: software that has to work inside a specific business, with that business's data and rules, needs someone on the ground who can build it there. As more companies buy AI platforms instead of building everything themselves, that need grows.

When your business needs one

An FDE, or a partner who works the same way, is worth considering when several of these are true.

Your pilot is stuck. The demo worked and the pilot never reached production. The blockers are integration, data access, permissions, or workflow fit, not the model itself. If that sounds familiar, the problem is deployment, and deployment is the FDE's job. The pilot playbook describes the same trap from the buyer's side: pilots that never become production systems.

The vendor's software does not land. Your team bought a platform, the vendor's customer success team ran the onboarding, and months later adoption is still low. The gap may go beyond training: the system may need changes to fit how your people actually work. An FDE can help when closing that gap requires hands-on engineering alongside your team.

Your data and security rules are strict. Some documents cannot leave your infrastructure, some industries require audit trails the vendor does not offer, and some access rules are too specific for a standard setup. When the deployment has to respect those rules in code, not just in a policy document, you need an engineer who works inside them.

Your AI use case runs on real documents. Retrieval, agents, and automation only work when they read your actual data and act through your actual systems. That integration work, connecting models to warehouses, ERPs, and document stores, is the FDE's daily work, and it is where generic implementations usually fail.

You have no internal team for it. Your engineers are busy running the business's own systems. Borrowing them for a deployment means the deployment competes with everything else, and it usually loses. An FDE or an embedded partner team brings the deployment capacity without the hire.

When you do not need one

The model is not for every project, and saying so is part of using it well.

A standard software rollout with clear requirements and a vendor who has done it a hundred times does not need an embedded engineer. Neither does a one-off task with a defined end, or a project where your own team already has the platform skills and the time to do the work. If the workflow is stable, the data is clean, and the integration is a standard connector, the deployment is a configuration task, and paying for an embedded engineer is paying for capacity you do not need.

The test is simple: if the hard part is understanding your business and adapting software to it, the model fits. If the hard part is choosing between two products, or configuring a standard one, it does not.

Hire an FDE or work with a partner?

If the need is real, the next question is whether to hire or to bring in a partner. Both are legitimate, and the answer depends on how long the need lasts and how broad it is.

Hiring makes sense when the deployment work is ongoing and your business needs someone to own it internally. If your business runs on a single vendor's platform for years, an in-house FDE becomes the person who knows how that platform meets your business, and the knowledge stays in the building. Depending on the responsibilities, that may be an integration engineer, an AI engineer, or a technical lead with deep platform expertise. The cost is the hire itself, the time to find someone with both engineering depth and customer-facing judgment, and the fact that one person can only cover so much.

A partner makes sense when the need is a defined engagement, or when it spans several capabilities. A studio like Ridiculous Engineering works this way in its AI Development and Automation and Software Consulting and Delivery Support engagements: engineers work within the client's environment and alongside their team to understand the workflows, build the integrations and the automations, and validate the solution together, and hand over a system the client's team can run. The partner brings a team instead of one person and covers more of the stack. Knowledge transfer, training, and documentation happen throughout the engagement, so when the partner leaves, the client's team has the understanding, skills, and documentation to run and maintain the system.

There is also a middle path: start with a partner engagement to get the system into production and learn what the ongoing work actually looks like, then hire for the steady state with real knowledge of the role. A pilot engagement produces the numbers that settle the hiring question: how much deployment work the system really needs, and how often.

What to look for in an FDE engagement

Whether you hire or bring in a partner, five checks separate a good engagement from one that ends in another stalled system.

1. Production ownership. The engineer or team owns a working system in production, not a design document or a demo. Ask what "done" means, and make the answer a system your people use, not a milestone on a slide.

2. Handover and training. The customer's staff can use and maintain the system after the engagement ends. Training, documentation, and a named owner on your side are part of the scope, not extras to negotiate later.

3. Evaluation. The system is tested against real work and clear success measures. For an AI deployment, that includes representative questions, documents, or tasks, with expected outcomes and checks for unsafe behavior. Repeat the relevant tests after changes so users are not the first to discover that quality has slipped.

4. Security and permissions. The system respects who may see information and take actions, and those controls are tested with real user accounts, not assumed from a settings page. Where relevant, the engagement should cover audit trails and data residency in code, not only in the contract. The governance angle matters here, and it is worth reading the LLM governance framework before you scope the deployment.

5. An exit plan. You know what happens when the engagement ends: who owns the system, what the ongoing maintenance looks like, and what it would take to move to another partner or bring the work in-house. The cheaper option to enter is not always the cheaper option to leave.

Frequently asked questions

What is a forward deployed engineer?

A forward deployed engineer is a software engineer who embeds inside a customer's organization to build, configure, and ship working software on the employer's platform, inside the customer's own data, security rules, and workflows. The role was popularized by Palantir around 2009 and now appears at AI labs, cloud providers, and consulting firms. The job is judged by whether the system runs in production and does useful work.

Is an FDE a consultant?

The roles can overlap. An FDE combines customer-facing problem solving with hands-on engineering to deploy working software in a customer's environment. Consultants may provide advice, implementation, or both. The useful distinction is the agreed responsibility: does the engagement include building and delivering a working production system?

Do FDEs only work at Palantir?

No. Palantir popularized the role, but FDE positions now appear at other companies, including AI labs, enterprise software companies, and consulting firms, including OpenAI, Anthropic, Databricks, Scale AI, and Microsoft. The responsibilities vary by employer, so look at the work and accountability behind the title.

What skills does an FDE need?

Production engineering first: the languages and systems the platform runs on, data pipelines, APIs, and debugging in live environments. Then the skills that make the embedding work: understanding a customer's workflow quickly, scoping an ambiguous problem into a deliverable with clear success measures, communicating with non-technical stakeholders, and training the customer's team. The rare combination is depth in both: an engineer who can read a production log and run a meeting with a vice president.

How long does an FDE engagement take?

It depends on the scope, the state of the data, and how clear the success measures are. A narrowly scoped pilot, one workflow with accessible documents and a fixed success measure, typically takes weeks. A production deployment involving several systems, security reviews, and organizational changes can take considerably longer. Timelines stretch when documents are scattered, permissions are unclear, or the scope keeps growing. Agreeing to a fixed pilot scope, clear success measures, and a decision checkpoint for the next stage before work starts helps prevent an open-ended engagement.

What does it cost to work with an FDE?

It depends on the volume of work, the complexity of the integration, and whether you hire or bring in a partner. That is exactly why a scoped pilot comes first: it turns a vague estimate into a real number based on your systems and your documents before you commit to anything bigger. Treat the cost as a model you refine through the pilot, not a number you calculate once.

The bottom line

The forward deployed engineer addresses a real gap: turning software into something that works within a specific business. Popularized by Palantir, the approach is gaining wider attention as companies work to put AI into production. The value comes from combining an understanding of the customer's work with the engineering needed to make the deployment useful. Models can be easy to demo. Making them work reliably within a business is harder, and closing that gap is central to the FDE’s job.

Whether you hire one or work with a partner, the test is the same. Name the production outcome, scope a pilot you can measure, and make handover part of the deal. If the system works in production and your team can run it, the model has done its job.

If you want help working through that decision, talk deployment with our team: the documents, the integrations, and a pilot you can measure, before making a bigger commitment.