Commercials

What forward deployed engineering costs

Two compensation figures for this role are traceable to a source. Levels.fyi reports Palantir forward deployed engineer total compensation in the United States with a median of $278,000 and a range from $185,000 to $631,000, read on 8 September 2026. Across 1,000 job postings analysed by Revealera and published in November 2025, the median advertised salary was $173,816. Everything else circulating is unsourced. Load one of those two for benefits, travel and unbilled time to get your input cost, then compare it against the cost of the deployment not happening.

Key takeaways

  • Two verified anchors: Levels.fyi Palantir median total compensation $278,000 (read 8 September 2026), and a $173,816 median advertised salary across 1,000 postings.
  • Salary is not the cost. Load it for benefits, travel, unbilled time between engagements and the productization time you deliberately fund.
  • Travel is a real line. 68 percent of postings require it and 50 to 75 percent is typical where a figure is given.
  • The third column is the cost of the deployment not happening, which is the one that usually decides the answer.

This page is the buyer's cost model. It uses only figures we could trace to a source, and says plainly where no figure exists.

The two verified anchors

Palantir forward deployed engineer total compensation: median $278,000, range $185,000 to $631,000. Self-reported to Levels.fyi, United States, read on 8 September 2026. Total compensation includes base, stock and bonus. Self-reported aggregator data skews toward people who choose to report, so treat it as indicative rather than as a market average.

Median advertised salary $173,816. Across 1,000 postings carrying the title, analysed by Revealera and published in November 2025. This is base salary as advertised, across companies of all sizes, which is why it sits well below the Palantir total-compensation figure.

The two are measuring different things. Use the advertised median for a general market sense and the Levels.fyi figure for what a mature programme at a large company actually pays.

What we will not give you

A frontier-lab band. Levels.fyi does not have enough submissions to show a level breakdown for OpenAI's forward deployed engineer title. Confident ranges for OpenAI and Anthropic appear in many blog posts and we could not trace one to a primary source, so we do not publish them.

A day rate for vendors. Nobody publishes these credibly and they vary by an order of magnitude with geography and model.

An average engagement cost. It depends entirely on deployment length, which nobody has published a defensible distribution for.

Where a number is not knowable, saying so is more useful than guessing. The statistics page lists everything else in the same category.

From salary to actual cost

Salary is the input. The cost is bigger, and the gap is where hiring plans go wrong.

Benefits and employment costs. Payroll taxes, insurance, equipment, software. Your finance team has this multiplier.

Travel. A real line for this role, not a rounding error. 68 percent of postings require travel and 50 to 75 percent is typical where a figure is given. OpenAI states up to 50 percent on its own postings. Somebody at 50 percent travel generates flights, hotels and per diems most of the year.

Unbilled time. An engineer is not on customer work twelve months a year. Holiday, the gap between engagements, internal work, and onboarding to a new account. Two-thirds of the year on customer deployments is a starting planning figure and should be replaced by your own measurement.

Productization time. If you are running the loop, and you should be, that time is funded and not billable. It is the cost that buys the compounding.

Management and support. An account owner, and somebody senior reviewing deployments.

The practical output: cost per engineer-month of actual customer-facing deployment work, which is meaningfully higher than salary divided by twelve.

The comparison that decides it

Put three columns next to each other.

Column one: build it. Loaded cost per engineer-month, times the engineer-months a deployment takes, plus the hiring cost and the ramp. Add a hiring timeline in months, because the delay has a cost too.

Column two: buy it. A vendor's price for the same outcome. Higher per unit of time, and it starts sooner, carries the delivery risk, and has no hiring risk. Three routes to the capability compares the options.

Column three: do nothing. The cost of the deployment not happening. This is the column people forget and it usually decides the answer.

What goes in column three: the revenue from the contract that will not close without the deployment, the renewal at risk, the pilot that dies in place. MIT NANDA reported in July 2025 that 95 percent of generative AI pilots produced no measurable profit-and-loss impact, across 52 executive interviews, 153 leader surveys and 300 public deployments. If your pilot is heading for that outcome, its whole cost so far belongs in column three.

The floor to write down

Before any of the above, one number.

Take the loaded cost of one engineer for the length of a typical deployment. Compare it to the annual contract value of the accounts you would deploy on. If the deployment cost is a large share of the contract, the model does not work at your current pricing.

First Round Review reports Looker validating $25,000 or more in annual contract value before committing to the model, alongside a trajectory toward 2,000 customers and $100 million in recurring revenue. Do not adopt $25,000; do the same calculation and write your own floor down before the first engagement, because working it out afterwards is how a company discovers it has built a services arm by accident.

Why our price is different

Stated plainly because it is the substance of what we sell rather than a claim about quality.

We use AI to write the code instead of hiring more engineers, and every change has to pass an eval suite derived from the specification before it reaches your branch. The saving from that goes into the price rather than the margin. The parts of an embedded engagement that still take human time, discovery, integration and getting through your approval path, are unchanged, so the saving applies to a portion of the work rather than to all of it.

We do not publish a percentage, because no discount has been measured and a number we cannot show the working for would belong in the same bin as the salary bands above.

Next: how to price it, or the contract terms.

Best for

  • Building a cost model for an embedded engagement
  • Comparing building the function against buying it
  • Setting the contract-value floor before the first engagement

Avoid if

  • You want vendor day rates, which nobody publishes credibly

Verify before you commit

  • Load salary for benefits, travel, unbilled time and funded productization time
  • Put a real number in the do-nothing column, including the contract that will not close
  • Compare one loaded engineer-deployment against the annual contract value of target accounts
  • Write the floor down before the first engagement, not after

Common questions

How much does a forward deployed engineer cost?

Two figures are traceable. Levels.fyi reports Palantir forward deployed engineer total compensation with a median of $278,000 and a range from $185,000 to $631,000, read 8 September 2026. Across 1,000 postings, the median advertised salary was $173,816. The first is total compensation at a mature programme, the second is advertised base across all company sizes.

What do OpenAI and Anthropic pay forward deployed engineers?

We could not verify a band for either, so we do not publish one. Levels.fyi does not have enough submissions to show a level breakdown for OpenAI's forward deployed engineer title, and the confident ranges circulating in blog posts do not trace to a primary source.

What costs are there beyond salary?

Benefits and employment costs, travel, which is a real line given 68 percent of postings require it and 50 to 75 percent is typical, unbilled time between engagements and during onboarding, funded productization time that is deliberately not billable, and management plus senior review. The useful output is cost per engineer-month of actual deployment work.

How do you compare building the function against buying it?

Three columns. Build: loaded cost times engineer-months, plus hiring cost and the cost of the hiring delay. Buy: a vendor price that is higher per unit of time but starts sooner and carries delivery risk. And do nothing: the cost of the deployment not happening, which is the column people forget and the one that usually decides.

What contract value do you need for the model to work?

Calculate your own floor by comparing one engineer's loaded cost over a typical deployment against the annual contract value of the accounts you would deploy on. First Round Review reports Looker validating $25,000 or more in annual contract value before committing, though your costs and margins differ so the number should be yours.

Why would an AI-native vendor cost less?

Because using AI to write the code instead of hiring more engineers means the same build takes a smaller team, and that saving can go into the price. It applies to a portion of the work: discovery, integration and getting through an approval path still take human time. We do not publish a percentage, because no discount has been measured.

More in Commercials

How to price forward deployed engineering

There are four ways to price embedded engineering: time and materials, fixed scope, outcome, and bundled into a licence. Each produces different behaviour, and the behaviour matters more than the rate. Billable hours pay the vendor to be slow and to keep the engagement going. Fixed scope pays them to argue about scope. Outcome pricing aligns both sides and is hard to write. When AWS announced its own forward deployed engineering organization it said the work would be structured around shared goals and business results rather than billable hours, which is a standard worth holding every vendor to.

Outcome-based pricing for embedded engineering

An outcome you cannot measure on the day of signature is a hope with a payment schedule attached. A workable outcome passes three tests: it is observable rather than inferred, somebody named takes the measurement, and neither party can move the goalposts unilaterally. The most reliable outcome for an embedded engagement is the least exciting one, which is a defined system running in production for real users by a named date. Business-metric outcomes sound better and fail more often, because neither side fully controls them.

Measuring forward deployed engineering

Measure four things: time from contract signature to production, the share of engagements that reach production, revenue per embedded engineer over time, and what came back into the product. Do not measure utilisation. Utilisation rewards keeping engineers on accounts, which is exactly the endless engagement this model fails into. The metric that matters most to a customer is time to production, and the metric that tells you whether you have a business is revenue per engineer rising rather than staying flat.

Revenue per forward deployed engineer

Revenue per embedded engineer, tracked over time, is the single number that tells you which business you are in. It has to rise. When the platform absorbs what the field learned, each engineer covers more ground and the number climbs. If it stays flat while custom work accumulates, you are running a services shop that has not admitted it yet. The benchmark for what a rising curve looks like is the previous generation: ServiceNow's gross margin at IPO was 63.2 percent and Workday's 54.1 percent, reaching 79 and 75 percent by 2024.

The contract for an embedded engagement

Before an outside engineer touches your repository, six things belong in writing: IP assignment on creation, scoped repository access rather than organization-wide, production access as a named exception with an audit trail, a production date, a handover date with a defined artefact, and subcontractor binding. The one people get wrong most often is the first: an NDA covers secrecy and does not assign ownership of what the vendor creates. Those are two separate clauses and you need both.