Buying forward deployed engineering: you sit on the customer side of Palantir's square
Buying forward deployed engineering as an industrial company is not copying Palantir's go-to-market. Anthropic engineer Kevin Bai's fit-test is for vendors selling a complex platform to a non-technical buyer. Pexon treats the customer's SAP, MES and PLM as the platform the engineer works on, so the ontology stays in the tenant rather than in a vendor product.
Kevin Bai's Forward Deployed Engineering 101 is a talk for people building a go-to-market. If you are buying the engineers, you are the other axis of his square.
Bai's fit-test, read from the side that writes the purchase order
| What is being sold | Who is buying it | How the gap closes |
|---|---|---|
| GitHub, Datadog | CTOs, CIOs, software engineers | They absorb the complexity. No FDE. |
| Slack, Jira, Rippling | Non-technical buyers and users | They configure it. No FDE. |
| A platform you have to develop on | A non-technical industry buyer | The vendor loans engineers. This is the only cell Bai says needs FDE. |
The square is from Kevin Bai's AI Engineer talk, Forward Deployed Engineering 101. He built Rippling's FDE function from the first hire to about twenty-five people in a year, after Palantir. The industrial company in cell three is not being told how to staff an FDE team. It is the buyer the team exists to close.
The two gates are for vendors. Invert them before you sign.
Bai's advice to anyone copying the function is blunt. Need it, or is it in vogue. The need is a corner case: you must take a technically complicated product to a non-technical buyer. If that mismatch is absent, he sends you to developer relations or to a sales-led motion. Without a platform of shared primitives, the engineers who make you money leave a maintenance burden that eats the P&L, if they do not quit first.
Those two questions belong to vendors. A plant with SAP does not need them.
The purchase test is gate one, flipped. Is a vendor selling you something you cannot operate without their people in the building. If yes, you are buying their go-to-market, and you should price the platform together with the people. If nobody is selling you that product, you do not need their FDE function. You may still need an engineer who will sit in your tenant and make a use case run. Bai's square has no cell for that. He was not talking to you.
Palantir's 2019 blog already split the roles: a Dev owns one capability for many customers, a Delta owns one customer and many capabilities on Palantir's platforms. That is a machine that works. It is also a decision to make Foundry the place where your warehouses become a proper noun. Treat it as that decision. A job title on a contractor's SOW is not the same object.
If you were to implement an FDE function where each FDE is building entirely from scratch, my friends, you do not have an FDE function, you have a dev shop.
Four things you can buy that all get called forward deployed
| Purchase | Where the work lives | What you own afterwards |
|---|---|---|
| Platform plus vendor FDE | Their ontology, their primitives | Their platform, with your data mapped into it |
| Engineer in your tenant | Your SAP, MES, PLM, your cloud | Your systems, their code in your repository |
| Staff augmentation | A backlog somebody else wrote | Capacity. Design risk stays with you |
| Strategy consulting | A document | A recommendation. Implementation risk stays with you |
Bai's line about the dev shop is the one vendors quote at each other. Read from the buyer's side it is a warning about row one done badly, and a description of row two done honestly. Palantir's S-1 is explicit about which row they sell: FDEs travel to factories to deploy Palantir's platforms, and time in the field improves those platforms. That feedback loop is the point of the model. It is not a free property of anyone who sits on site.
Your source systems are already the platform. Foundry is a second one.
Bai's working example is Foundry. Data is centralised, an ontology is built, and applications sit on top. The industry leader's reply, in his telling, is that organised data is not yet a business result. Shelf placement and sales throughput are. The FDE exists to close that gap by assembling primitives into an outcome, so the customer is not asked to become a Foundry developer as a precondition of value.
It is a weak argument for hiring anyone titled FDE.
A mid-market manufacturer already has the nouns in SAP, the MES, and the PLM. Entitlements grew by accident. Schemas differ by plant. The failure mode of an AI project there is not that nobody lent you a Foundry specialist. It is that the planned approach cannot read production data under the permission model that actually exists. An engineer who only knows how to assemble someone else's primitives will discover that once the ontology mapping is already a programme.
Pexon takes the other side of Bai's second gate. The shared primitives are the customer's ERP, line systems, cloud tenant and identity provider. The engineer works there. Code lands in the customer's repository. Inference stays in the tenant if security asked for that. We do not get Palantir's ACV, because we do not own the ontology you leave with. That is the trade we will put in writing.
Four million dollars is not a mid-market purchase order
Bai's Palantir ACV against Pexon's published ladder. These are different purchases, not a currency conversion.
Palantir ACV
$4 million
Bai, 'last I checked'. Platform plus engineers, Fortune-500 public-SaaS comparison.
Entry sprint
€4,900
Two weeks, fixed. Architecture against your source systems, not a platform licence.
One engineer / month
€7,500
Named forward deployed engineer, monthly, not a day-rate against a backlog.
Twelve months of one engineer
€90,000
Still not Palantir's package. You keep SAP. They keep Foundry.
The four-million-dollar figure is Kevin Bai's recollection in the talk, with no date and no stated methodology. Palantir's S-1 describes the FDE motion and does not publish a matching average contract value in the passage we used. ServiceNow at $1.2 million and Workday at $600,000 are the same recollection; Workday he flagged as tentative. Euro figures are Pexon's published pricing ladder. Do not convert the dollar figure into euros and call it a comparison. The point of the strip is that the objects differ.
When Palantir's model is the right buy, and when it is a job title on the wrong contract
The consensus holds
- You want their ontology. Foundry as the place warehouses, orders and materials become one object model is a product decision. Pay for it as one.
- The contract can absorb platform economics. Bai's ACV comparison is a Fortune-500 SaaS stack. If that is your peer set, their GTM is built for you.
- You cannot operate the product without their people. That is gate one, uninverted. The engineers are part of the licence, not a substitute for it.
The consensus does not hold
- You already run SAP, MES and PLM. A second ontology is a second source of truth. The engineer should start at the systems that already hold the nouns.
- The first job is whether the data can be reached. Permissions, plant-level schemas, works-council paths. None of those are Foundry features. They are why the pilot died.
- You need one use case in production, not an operating system. A two-week blueprint is the cheap way to find that out. A multi-million platform contract is not.
- The title on the SOW is FDE and the billing is hours. That is staff augmentation. Bai would call it a dev shop. Both are fine. Price them as what they are.
What this costs us to say
We sell the second row, and we will never show Palantir's contract value, because we do not own the platform the customer leaves with. The strongest argument against us is Bai's own: without shared primitives you have a maintenance problem, not an FDE function. We accept that argument and locate the primitives in the customer's ERP, MES, PLM and identity provider rather than in a product we licence. If that is the wrong trade for you, buy the platform. The role definition, without this choice attached, lives on the about page.
Keep reading
- SAP data layer for AI: one answer, traceable to the row — the buyer's platform is already there. This is what the engineer has to reach.
- What a forward deployed engineer actually does — the role definition, without the Palantir-GTM argument. Day-to-day, first fortnight, when not to buy.
- Permission-aware retrieval: why pilots die at access control — the failure that shows up in week three, which no ontology mapping postpones.
- MES production data for AI — the other system of record besides SAP, and the one whose schema differs by plant.
Questions buyers ask after the Palantir talk
Should we copy Palantir's forward deployed engineering model?
Mostly yes, if you are selling a complex platform to a non-technical buyer. That is Kevin Bai's gate, and Palantir's S-1 describes FDEs as the people who deploy Palantir's platforms. If you are the industrial buyer, the model describes the vendor's economics. Buy Foundry on purpose, or buy an engineer who works in your tenant. Do not buy the label on a services contract.
What does buying forward deployed engineering cost?
Pexon prices the blueprint at €4,900 and one engineer from €7,500 a month. That is not Palantir's package: Bai cited a four-million-dollar average contract value, last he checked, covering platform plus engineers. All prices are net and exclude VAT. A day-rate against a backlog is staff augmentation, whatever the job title on the SOW.
When should we not buy forward deployed engineering?
Skip it when the work is repeatable or already staffed. One well-specified integration against a documented API is a fixed-price job, not an embedded engineer. Bai's inverse holds too: if nobody is selling you a product you cannot operate, you do not need their FDE function. You may still need an engineer. Those are different purchases.
Is a Palantir FDE the same as an engineer working in our tenant?
No, a Palantir Delta and a tenant engineer are different purchases. Palantir's Delta builds on Foundry primitives: one customer, many capabilities, on their platform. An independent engineer works against your SAP, MES and PLM, in your tenant, in your repository. The first fortnight can look similar. What you own in month twelve is not.
Do we need Foundry or an ontology before an FDE can start?
No, Foundry is not a prerequisite before an FDE starts. You need reachable source systems and a permission model that will survive retrieval. An ontology is one way to turn tables into business objects. It is not required before an engineer can read SAP, MES or PLM. If you want Palantir's ontology as the operating system, buy Palantir.
Next step
The cheap way to find out which purchase you are making
Two weeks, fixed price. You end with an architecture against your actual source systems, a cost figure, and a written answer to whether the work should live in your tenant or on someone else's platform. If the honest answer is that you should buy the platform, that is what it says.