Forward deployed engineering: the complete guide

A forward deployed engineer is a software engineer who is placed inside a customer's organization to build and ship software there, against that customer's real data and real constraints, and who stays accountable until the system is running in production.

That is the definition. The rest of this guide is about why the role exists, why it is suddenly everywhere, how it differs from the four or five adjacent jobs people confuse it with, how to hire for it or buy it, and what it pays. We wrote it because the role is being described in a lot of places by people who are selling something and citing nothing, and a buyer or a candidate trying to understand it deserves better than recycled numbers.

Where the name comes from

The term is borrowed from the military, where a forward deployed unit is stationed in the field rather than at home base. Palantir Technologies popularised it in software, and the reason it invented the role is the most useful thing to understand about it.

Palantir's early customers had problems nobody could specify in advance. The customer could not write a requirements document, because the customer did not know what the software should do until they saw something working against their own data. A traditional delivery model breaks on that. You cannot run discovery, write a spec, go away for six months, and come back, when the discovery itself is only possible inside the environment.

So the engineer moved to where the problem was. Not an analyst who reports back, and not a consultant who writes a recommendation. An engineer who commits code, sits in the customer's standups, and finds out what is true by building against the actual systems.

Wikipedia's entry on the forward deployed engineer records the same origin and notes that the responsibilities overlap with solutions architects, sales engineers, customer engineers, professional services engineers, systems integrators and IT consultants [1]. That overlap is real, and it is why half of this guide is comparison pages. The overlap in tasks hides a difference in accountability that decides everything else.

What actually distinguishes the role

Three things separate a forward deployed engineer from the roles that look like it.

They write production code. Not diagrams, not runbooks, not a proof of concept that someone else industrialises. Code that goes into a repository and runs.

They work in the customer's environment. The customer's data, the customer's authentication, the customer's approval process, the customer's staging environment that does not match production. Working from the outside means working from a description of the environment, and the description is always wrong in the places that matter most.

They are on the hook for the outcome. The deployment either runs or it does not, and the FDE does not get to hand the failure to an implementation team. This is the part that cannot be faked, and it is the fastest way to tell a real FDE function from a rebadged professional services team.

Our page on what a forward deployed engineer is goes through the definition properly, and what a forward deployed engineer does walks a normal week.

Why the role is spreading now

The role existed quietly for twenty years. Then, over about eighteen months, it became one of the most-discussed jobs in the industry. Three things happened at once.

The first is a gap between AI demos and AI in production. MIT NANDA's July 2025 study, "The GenAI Divide: State of AI in Business 2025", drew on 52 executive interviews, 153 leader surveys and 300 public deployments, and reported that 95 percent of generative AI pilots delivered no measurable profit-and-loss impact [2]. That number gets quoted everywhere, usually without the sample size, and it deserves the caveat. What it describes, though, matches what anyone selling AI into a large company sees: the model works, the pilot impresses people, and then it dies in the distance between the pilot and the workflow.

The second is that investors started arguing for it out loud. In June 2025, a16z partner Joe Schmidt published "Trading Margin for Moat", which argued that AI companies should hire implementation-heavy teams instead of chasing product-led growth, and called the forward deployed engineer the hottest job in startups [3]. His evidence is the previous generation: ServiceNow's gross margin at IPO was 63.2 percent and Workday's was 54.1 percent, well below the 80 percent that software investors treat as normal, and both later climbed, to 79 percent and 75 percent in 2024. The services work was the on-ramp, not the business model.

The third is that the largest cloud provider made it a product. In June 2026, AWS announced a Forward Deployed Engineering organization backed by a $1 billion investment, embedding thousands of engineers with customers to build production AI systems, and said the work would be structured around shared goals and business results rather than billable hours [4]. A month is a short time in enterprise software and a $1 billion commitment is a long one. When the incumbent cloud starts selling embedded engineers, the model has stopped being a Palantir eccentricity.

Why forward deployed engineering is growing covers all three in detail, with the numbers and their sources.

The four roles people confuse it with

This is where most of the confusion lives, and the distinctions are worth being exact about.

A sales engineer works before the contract. They demo, they answer technical objections, they build the proof of concept that gets the deal signed, and their compensation usually moves with bookings. When the contract closes, they leave.

A solutions architect designs the implementation. They produce the architecture, the integration plan, the reference pattern that makes the deployment repeatable. Someone else builds it.

A consultant or professional services engineer delivers an agreed scope. The scope is the contract, the statement of work defines done, and the engagement ends when the scope is delivered, whether or not the thing produces value.

A forward deployed engineer does the part after all of those. They own the build and the production rollout, they change the plan when the environment says the plan was wrong, and they finish when the system runs.

Six comparison pages in this guide take each one properly: FDE vs solutions architect, FDE vs sales engineer, FDE vs solutions engineer, FDE vs consultant, FDE vs systems integrator, and FDE vs staff augmentation, which is the fork most buyers are actually standing at.

The economics, stated plainly

Forward deployed engineering is expensive. An engineer assigned to one customer is an engineer not building the product, and the cost lands on gross margin where every investor can see it. Anyone who tells you the model is free is selling it.

What you buy with that margin is threefold. You get deployments that reach production instead of stalling. You get a view of the customer's real workflow that no discovery call produces. And you get to see which customer-specific work repeats across accounts, which is how a services motion turns back into product.

That last part is the hinge. First Round Review's February 2026 piece on hiring FDEs makes the point that the discipline is knowing when to stop: expand scope when the work creates something reusable, and stop when the iteration only ever serves one customer [5]. It also gives a rough allocation for how the time should split, around 20 percent facing the customer and 80 percent building, which is a useful sanity check on whether you have hired engineers or account managers.

How to price forward deployed engineering works through the models, and measuring forward deployed engineering covers what to track so the function does not quietly become a cost centre.

When it is the wrong answer

We are a consultancy that works this way, so treat the following as the part we have the least incentive to write.

Forward deployed engineering is the wrong model when your customers are small, when your product does the same thing for everyone, when your contract values cannot carry an engineer's time, or when you already know exactly what the product should be and are not willing to change it based on what one customer needs. First Round's diagnostic is blunt about the last one: if you hold strong opinions about product direction and do not want them moved, FDEs are a bad fit [5].

There is also a failure mode worth naming. An FDE engagement that never ends has stopped being a deployment and become a dependency. The customer's team never learns the system, the vendor's margin never recovers, and both sides call it a partnership. AWS's own framing puts self-sufficiency at the end of the engagement as a design goal [4], and that is the right test: at some agreed point, the customer's engineers run this without you.

When forward deployed engineering is the wrong answer is the page for that conversation.

What it costs

Whether you build the function or buy it, the number that matters is what one embedded engineer costs you for a quarter, against what the deployment is worth.

Two figures are checkable. Levels.fyi, read on 8 September 2026, puts self-reported Palantir forward deployed engineer compensation in the United States at a median total package of $278,000, with a range from $185,000 to $631,000 [7]. Across 1,000 job postings analysed by Revealera and published in November 2025, the median advertised salary was $173,816 [8]. Load either one for benefits, travel and the time the engineer is not on another account, and you have the real input.

Almost everything else circulating about this is unsourced. The confident frontier-lab bands in the search results trace back to blog posts citing each other, and Levels.fyi does not yet have enough submissions to show a level breakdown for OpenAI's forward deployed engineer title. What forward deployed engineering costs works the model through from the buyer's side and names what is not knowable.

Travel is the other real cost, and it is on the people doing the work. OpenAI's own postings for forward deployed software engineers state that up to 50 percent travel is required [6], and 68 percent of the 1,000 postings analysed required travel at all, with 50 to 75 percent typical where a figure was given [8].

Three routes to the capability

You can build the function, staff individual engineers through a partner, or engage a firm that takes the outcome. Forward deployed engineering as a service compares the three on cost, speed and where the delivery risk sits.

If you are building it yourself, start with how to build the team, then the job description and how to hire. One decision matters more than the rest, and it is where the function reports.

If you are buying it, how to choose a partner and the questions to ask a vendor are the two pages to read before you take a call, and what to put in the contract is the one to read before you sign.

Where this connects to the rest of our work

Forward deployed engineering and the way we build are the same argument arriving from two directions. An engineer inside your environment finds out what is actually true. A specification written from what they find, and an eval suite derived from that specification, is what keeps the code honest once a model is writing most of it. One without the other gives you either fast code nobody trusts or trustworthy code that solves the wrong problem.

If that is the part you care about, eval-driven development covers the verification method, AI-native delivery covers how the work is organised, and building AI products covers the product side. If you are choosing who to work with, choosing a software development partner is the buyer's guide.

And if you want this done rather than read about, that is what we do: tell us what you are building.