Forward deployed engineering explained for executives

This page is for whoever approves the spend. It assumes you do not need the history of the role and do want to know what you are buying, what it costs, and what to require of the vendor.

What you are buying

Engineers who work inside an environment rather than from outside it. They use the real data, the real authentication, the real approval process, and they are accountable for the system running in production rather than for a document describing how it should.

The alternative models are cheaper. A consultant will deliver a scope. An integrator will connect products that exist. Staff augmentation will add engineers to a plan you own. Each is the right purchase under conditions that are easy to state, and when forward deployed engineering is the wrong answer states them.

None of the cheaper models are wrong purchases. They fail only when bought for the wrong problem. A consultant is the right buy when you can already describe the system you want and only need somebody credible to write it down. An integrator is the right buy when the pieces already exist and the job is connecting them without breaking either side. Staff augmentation is the right buy when your own team already knows the plan and the constraint is headcount rather than judgment. The mistake this page exists to prevent is buying one of those three when the actual problem is that nobody, including you, can yet say what the finished system should do.

Why the model exists at all

Because AI systems cannot be specified in advance the way earlier software could.

With a conventional integration, you could write down what the system should do, price it, and require a vendor to deliver it. With an AI system, nobody knows the acceptable error rate, the unusual cases, or the escalation path until it runs on real data with real users. The specification is something the work produces.

That is the mechanism behind the number everyone quotes. MIT's Project NANDA reported in July 2025 that 95 percent of generative AI pilots delivered no measurable profit-and-loss impact. Worth knowing the sample before you repeat it in a board meeting: 52 executive interviews, 153 leader surveys, and analysis of 300 public deployments. It is a strong sign of a real problem, and it does not cover every company.

The failures it describes are not model failures. They are data nobody audited, a success metric nobody defined before the work started, and users who were handed a workflow they had no part in designing. None of those can be fixed from outside the building.

Consider what a specification-first purchase actually requires of the buyer. You would need to know, before signing, which records are clean enough to trust, what a correct answer looks like in the cases where reasonable people disagree, and how the new workflow should behave when it is wrong. Almost no company can answer all three before the system exists, because the answers depend on watching real people use something real. That gap is a property of the work rather than a failure of planning. A specification for this kind of system is something the builder produces by being present while the problem is still being discovered, which is the entire argument for putting engineers inside the building rather than outside it.

The three questions that decide it

Does the contract value pay for an engineer? Work out what one engineer costs you loaded for a quarter, then compare it against what the deployment is worth. First Round Review reports that Looker validated $25,000 or more in annual contract value before committing to the model. Do not adopt that number, do the same calculation, and write the minimum down before the first engagement.

Do the environments differ from each other? Look at your last five implementations and count what was genuinely different in each. If the answer is a connection string and a logo, you have a documentation problem and an embedded engineer is an expensive way to solve it.

Will anybody act on what the engineers find? This is the one executives pay least attention to. The value of putting an engineer inside an environment is what they learn there, and that learning is only worth the cost if it can change what gets built. First Round Review is blunt: if you hold strong opinions about product direction and do not want them changed, embedded engineers are a bad fit. You will have paid for discovery you intend to ignore.

Two noes and the answer is no.

How to actually run the calculation. Take your fully loaded quarterly cost for one engineer at the seniority this work needs: salary, benefits, the recruiting cost amortised over expected tenure, and the overhead of managing somebody who works mostly outside your building. Compare that number against the contract value or the internal budget the deployment is meant to protect or create. If the deployment is worth less than that number over the period you would need the engineer, the arithmetic already answers the question, and no amount of enthusiasm about the technology changes it. Write the number down before the first conversation with a vendor, because a vendor's own case studies will always look compelling in isolation and the only defence against that is a number you decided on before you were in the room.

What it costs

Two figures are checkable, and almost everything else published is not.

Levels.fyi, read on 8 September 2026, reports self-declared Palantir forward deployed engineer compensation in the United States with a median total package of $278,000 and a range from $185,000 to $631,000. Across 1,000 job postings analysed by Revealera and published in November 2025, the median advertised salary was $173,816.

Add benefits, travel and the time an engineer is not on another account to either one, and you have the input. What forward deployed engineering costs works through the calculation, and names what is not knowable.

The other cost is margin. An engineer assigned to one customer is an engineer not building the product, and it reduces gross margin, which every investor sees. a16z's argument for accepting that is Trading Margin for Moat: ServiceNow's gross margin at IPO was 63.2 percent and Workday's 54.1 percent, both later rising to 79 and 75 percent by 2024. The early focus on services was the way in.

That history matters for a buyer, not only for an investor watching a vendor's margin line. It tells you what a healthy version of this purchase looks like over time. In year one, expect to pay for a person, because the value is genuinely their attention on your problem. By year three, if the relationship is working the way it should, less of what you pay for should be one person's time and more of it should be software that person built, which means your renewal price should reflect less bespoke labour, not the same amount at a higher rate. A vendor whose price per customer never falls as the relationship matures has not converted any of the discovery work into something reusable, and you are paying services rates indefinitely for what should have become product.

The two dates to insist on

This is the shortest useful thing on the page.

A production date. Not a design delivery date, not a pilot date. The date the system is running for real users.

A handover date. The date the vendor leaves and your people run it, plus what the handover artefact actually is.

When AWS announced its own forward deployed engineering organization in June 2026, it named customer self-sufficiency at the end of the engagement as a design goal, and said the work would be priced on business results rather than billable hours. Require both of every vendor, including us.

An engagement without those two dates is not a deployment. It is a recurring cost with an optimistic name.

A practical way to test whether the dates are real rather than decorative: ask what happens contractually if the production date passes without the system live. If the answer is nothing, silence, or a vague reference to continuing the relationship, the date was never a commitment. A production date that means something has consequences attached to it, the same way a handover date only means something if somebody on your side is named to receive the system and has calendar time set aside to learn it before the vendor leaves. A document dropped in a shared drive on the last day marks an ending, nothing more.

What to ask in the vendor meeting

Four questions, and the answers are more informative than the slide presentation.

What share of the week will these engineers spend writing code in our repository? Who is accountable by name if this does not reach production? Are they compensated on our system going live or on this contract being signed? And what is the handover date?

A vendor selling genuine forward deployed engineering answers all four directly. Questions to ask a vendor has the longer list, and the three different jobs that use the title explains why the first question matters: across 1,000 postings, 30 percent using this title were presales roles.

The decision in one paragraph

If the work can be written down, buy delivery. If it cannot, and the outcome is worth an engineer's full attention, and somebody on your side will act on what the engineers learn, buy forward deployed engineering with two dates in the contract. If you are unsure, the cheapest next step is not a pilot engagement. It is counting what was actually different about your last five implementations.

Then: three routes to the capability.