What Is a Forward Deployed Engineer?

The demo worked. The customer still can't use it.

A model can answer every question in the sales meeting, then stall when it meets the customer's real data, their security review, and the people who would have to use it every day.

A forward deployed engineer, or FDE, is the engineer a software company sends to close that gap. They work directly with one customer, figure out what the problem actually is, build the software that fixes it, get it running for real, and bring what they learned back to their own company's product.

Palantir pioneered the role. OpenAI, Scale AI, Ramp and other software companies now run their own versions, because their hardest customers don't need another demo. They need someone who can make the product work inside a messy business.

One customer, many parts of the product

Palantir draws the cleanest line. A regular software engineer builds one feature for many customers. A forward deployed engineer uses many features to get one customer a result.

That doesn't mean every line of code is custom. It means the FDE starts from what the customer needs and works backward through the product, the data, the systems it has to connect to, and the people who have to use it.

The easiest way to see the job is to follow one problem from start to finish.

One made-up problem, start to finish

Lakeside Bank isn't real. It's an invented example, and so is everything that happens to it below. The steps are the ones the job listings and Palantir's own engineering blog describe.

Discovery: the ask isn't the problem

Lakeside's fraud team gets alerts about suspicious payments all day. Their head of operations asks for "an AI assistant for investigators."

The FDE doesn't start building. They sit with a few investigators and watch them work an alert. Writing up the case isn't the slow part. The slow part comes first, when each investigator opens four different systems to piece together what the account has been doing before they can decide anything.

So the real problem is "investigators can't see an account's history in one place," not "we need a chatbot." That's discovery: separating what the customer asked for from what's actually slowing them down.

A smaller first version

An assistant that does everything would take months and fail in ways nobody could trace. So the FDE proposes something smaller. When an alert opens, the tool pulls the account's recent activity from those four systems into one page, with a link back to each source.

They also write down what's out of scope. The tool won't decide whether something is fraud. Investigators still make that call.

Before anyone writes code, they agree on how to tell whether it worked: how long it takes an investigator to reach a first decision, and how often they have to correct the summary. They also agree on what "done" means for the FDE's part, so the project has an end.

This is product management under a deadline. Picking the first use case, and saying no to everything else for now, is most of the skill.

Implementation: real software in someone else's building

Now the FDE writes code. This is where the role differs most from consulting. OpenAI's FDE description covers full-stack systems and production rollout. Palantir compares the job to a hands-on startup CTO. Scale AI asks for end-to-end development across the application and the infrastructure underneath it.

At Lakeside, that means things a demo never touches. The security team has to approve read-only access to each system. One of the four systems is old and has no clean way to get data out. Investigators should only see accounts they're allowed to see. The tool needs logs, so when it gets something wrong, someone can find out why.

None of that is glamorous. It's most of the work.

Evaluation: check it before people rely on it

Before investigators use the tool on live alerts, the FDE builds a test set from past alerts where the team already knows what happened. They run the tool on each one and compare its summary with what the investigators actually found.

The test catches a problem. Transfers from the old system are missing from some summaries. Nobody would have noticed in a demo, because a demo runs on clean data. The FDE fixes the connection and runs the test again.

Then a small group of investigators uses it for real. The FDE measures the two things everyone agreed on at the start, and watches whether people keep using it or quietly go back to the old way.

AI makes this step bigger than it used to be. A model can be confidently wrong, so it needs tests built from the customer's own cases, limits on what it can do, and monitoring that keeps running after launch.

Handoff: leave it running without you

The FDE won't be at Lakeside forever. Before leaving, they make sure someone owns the tool. The bank's platform team knows how it works, there's a written guide for when it breaks, and it's clear who gets the call when it does.

The second half of the handoff happens back at the FDE's own company. Suppose the connector for that old system is the third one the company has built for a bank. That's a sign it should become part of the product, so the next customer gets it on day one. Ramp calls this judgment, telling a one-off request apart from something the product is missing, one of the central arts of the role.

That last step is what separates an FDE team from expensive custom work. The model only pays off when what the field learns makes the product better.

Where the name came from

Palantir built the role while deploying software into high-stakes government and enterprise settings. A normal product spec couldn't capture what those customers needed. Engineers had to get close to the users, the data and the rules.

Palantir called these engineers "Deltas." Its engineering blog describes their job as delivering technical results for a customer, often with Palantir products alongside open-source and standard tools. Deltas could also fix or add to the core platform when customer work showed a need every customer shared.

"Forward deployed" is a military phrase. It means close to where things are happening, where information is incomplete and mistakes cost something. Today's FDEs may work on-site, hybrid or fully remote. What defines the job is how close they are to the customer's problem, not how often they fly.

Why AI companies want them now

Most software companies try to avoid custom work for each customer. One standard product, self-serve setup and shared support keep costs down. That still works when a product delivers its value through settings and documentation.

Big enterprise products don't work that way. Whether they deliver anything can depend on old systems, unusual data, security approvals, or people changing how they work. AI widens the gap, because a working deployment also needs tests built from the customer's cases, checks on how the model behaves, limits on what it can do, and ongoing monitoring.

An FDE shortens the loop. Normally customer feedback travels through Sales, Customer Success, Product and Engineering before anything changes. With an FDE, the engineer who hears the problem can look at the system and fix it. The customer gets value sooner. The product team learns what's actually blocking adoption.

Renaming an implementation engineer doesn't create an FDE team. The company has to give the FDE real authority to set scope, build, ship, measure and push for product changes.

What a normal week looks like

There's no standard FDE day, but a healthy week usually includes:

A session with the customer's staff to map how they work
Design work with the customer's security or platform team
Writing and reviewing code for an integration, an app, or a test setup
Testing with real data, or data that looks like it
A rollout session with users and their managers
A review with your own company's engineers and product team about what customers need
Written updates on results, risks, decisions and next steps

The mix changes over a project. Early on it's mostly discovery. The build looks like normal product engineering. After launch, the work shifts to reliability, helping people change habits, and measuring.

An FDE who spends every week in meetings is probably working as a consultant. One who only codes probably doesn't own the customer's result.

Travel depends on the company. OpenAI's San Francisco FDE listing stated travel up to 50%, while Palantir listings can set different expectations. Reporting lines vary too. FDE teams can sit in Engineering, Customer Engineering, a deployment group, or the sales side of the company. The healthiest ones keep production engineering standards and a close tie to Product, wherever they sit on the org chart.

How it compares with similar jobs

Role	What they're there to do	How much code	When they show up	How success is measured
Forward Deployed Engineer	Get one customer a result, and bring lessons back to the product	Production code	From discovery through adoption	Real change in the customer's operations, plus product improvements
Solutions Architect	Prove the product fits and design the solution	Prototypes and reference designs	Mostly before the sale and early setup	Technical sign-off and deal progress
Implementation Engineer	Set up and launch a defined product	Integration and configuration code	After the sale, during onboarding	Going live on time
Consultant	Study a problem and recommend or deliver change	Varies, often limited	Project by project	Deliverables and client goals
Core Software Engineer	Build product features for every customer	Production code	All the time	Product reliability, adoption and shipping speed

These lines aren't universal. Some companies call pre-sales engineers FDEs. Others use "customer engineer," "deployment engineer" or "applied AI engineer" for nearly the same work. Judge the job by what it asks you to own, not by the title. The FDE vs Solutions Architect vs Consultant comparison goes role by role.

The skills it takes

The role rewards engineers who go deep enough to ship safely and wide enough to understand the customer's whole setup.

Shipping software: coding, debugging, testing, system design, APIs, data, cloud infrastructure, security and logging.
Breaking down a vague problem: turning "investigations are slow" into work you can build and test, without losing the point.
Product judgment: knowing what to build, what to configure, what to put off, and what should become a feature for everyone.
Finding out what's really going on: asking useful questions, watching people work, noticing disagreement, and finding who actually decides.
Explaining tradeoffs to engineers, users, executives and risk teams without hiding what you don't know.
Keeping the project on track: holding scope, ordering the work, raising risks early, and keeping several organizations pointed the same way.
Learning a new industry fast without pretending to replace the customer's experts.

AI-focused roles add more: testing what a model produces, retrieval (finding the right documents to hand the model), agent design, prompt and tool design, safety, and working with a system that's sometimes wrong in ways you can't predict. How FDEs close the enterprise AI deployment gap covers that part.

When a company should have FDEs

An FDE team is worth what it costs when several of these are true:

A few big customers are worth a lot and have complicated setups.
Deals stall after the demo because nobody knows what production will take.
Core engineers keep getting pulled into customer projects.
Failed rollouts make customers leave or keep them from buying more.
Customer work keeps turning up features the product should have.
The first real use case needs deep integration or a change in how people work.
The company can charge enough, learn enough, or grow the account enough to justify scarce engineers.

It's usually the wrong call for a cheap product people sign up for and set up themselves. It's also wrong when the same deployment problem shows up at most customers. That's a product problem, and more FDEs just hide it. The FDE hiring decision framework walks through the call.

What goes wrong

When it works, the company learns faster, customers get value sooner, executives trust the vendor more, and the product gets sharper feedback.

When it doesn't, custom code piles up. Expensive engineers turn into permanent support. Sales promises work nobody has defined. Product teams write off field feedback as noise. FDEs burn out from travel, ambiguity and constant switching. Revenue looks like software while the work behaves like a services business.

The rules are easy to say and hard to keep. They're the same steps the Lakeside example followed:

Be picky about which projects you take.
Agree on the result, and on when you're done, before building.
Hold production engineering standards.
Measure whether people use it and whether it helped.
Hand off long-term operation on purpose.
Turn a fix you keep rebuilding into something the next customer can use.

The Forward Deployed Engineering playbook, FDE team scorecard and failure-mode guide turn these into working practices.

Pay and where the job leads

FDE pay varies a lot by location, seniority, company stage, equity, and whether the role includes sales bonuses. Job listings give useful snapshots, not one universal salary range.

As of August 10, 2026, OpenAI listed a San Francisco FDE base range of $162,000 to $280,000 plus equity. Scale AI's GenAI FDE listing showed $179,400 to $224,250 across several US locations plus eligible equity. Palantir's Forward Deployed AI Engineer listing showed $135,000 to $200,000 plus potential equity and incentives.

Listings change, so check the live posting. Compare total pay, travel, location, scope and career path, not just the base number.

The role can lead to staff engineering, product, engineering management, solutions leadership, customer engineering leadership, or starting a company. It builds unusual range. If you'd rather own one technical system deeply without constant interruptions, core product work may suit you better. The career guide and FDE interview guide cover how to get in.

Where to go next

Pick the guide that matches the decision in front of you:

Compare the role with similar jobs: FDE vs Solutions Architect vs Consultant
Decide whether to hire one: When Should You Hire a Forward Deployed Engineer?
Set up the team: How to Build a Forward Deployed Engineering Team
Run a customer project: The Forward Deployed Engineering Playbook
Measure the team: How to Measure FDE Teams
Deploy enterprise AI: Forward Deployed Engineers for Enterprise AI
Get into the field: How to Become a Forward Deployed Engineer
Prepare for interviews: Forward Deployed Engineer Interview Guide
Avoid the common mistakes: Why Forward Deployed Engineering Teams Fail