Origins and Economics

The bet, in Palantir's own numbers

The role's history matters for one reason: it was an economic decision before it was a job title, and the economics still shape every engagement you will work on. The decision is easiest to see in the one place a company published its own numbers.

The best public record of the bet is Palantir's 2020 S-1 filing (Palantir S-1; T2, company-reported in a regulatory filing). It names the role directly: "Our forward deployed engineers ('FDEs') have travelled to bases in Afghanistan and factories in the industrial Midwest to deploy our platforms." And it says what the company gets for sending them: "As FDEs help customers make the most of our software, they observe users' challenges firsthand." Elsewhere it credits its platforms to "the systematic incorporation of improvements identified by our software engineers working in the field". The filing then sorts every customer into one of three phases and reports what each phase earned in 2019.

PALANTIR, 2019, BY CUSTOMER PHASE (S-1, contribution margin)

Phase     Defined by                        Revenue   Contribution
Acquire   under $100K revenue that year     $0.6M     loss of $65.4M
Expand    over $100K, margin negative       $176.3M   (43)%
Scale     over $100K, margin positive       $565.7M   55%
  top 25% of Scale, ranked by margin        $110.7M   87%
All customers                               $742.6M   21%

Read down the rows and you see the shape of the bet. In the Acquire phase Palantir runs "short-term pilot deployments of our software platforms at no or low cost", and "During these short-term pilots, we operate the accounts at a loss." In the Expand phase it keeps losing money on purpose: "we operate at a loss, as measured by contribution margin, in order to drive future revenue growth and margin expansion." In the Scale phase customers become "more self-sufficient", and the margin turns. The top quarter of Scale customers ran at 87%. Before the Engagement has already covered what the Acquire-phase loss means for how a pilot is priced. This chapter is about the whole curve.

The 87% is the most quoted number in the table, so it is worth knowing what it isn't. Four things limit it, all of them in the filing.

• It is selected on the outcome. It is the top 25% of Scale customers ranked by contribution margin, so it is the best quarter by construction. Those customers brought in $110.7 million, 20% of Scale revenue.
• The phases are defined by the result. An Expand customer is one whose margin was negative that year, and a Scale customer is one whose margin was positive. Scale customers are profitable because that is what "Scale" means, so the table can't tell you how many customers move from one row to the next.
• No conversion rate is given. The filing warns there is "no guarantee that we will be able to move customers from the Acquire phase into later phases", and it never says how many do.
• Contribution margin leaves out costs. It is "revenue less our cost of revenue and sales and marketing expenses, excluding stock-based compensation, divided by revenue". Research and development isn't in it, and neither is general overhead. It is a non-GAAP measure, and the company-wide figure for 2019 was 21%.

None of this makes the 87% false. It makes it the best case, and you should read it as one. The more useful numbers for an FDE are the ones the filing gives for the same customers six months later. The accounts that were in Expand at the end of 2019, running at (43)%, ran at 35% in the first half of 2020. The Scale accounts rose from 55% to 68%. The 2019 Acquire accounts brought in $18.8 million in that half-year and still lost $13.9 million. A half-year is not a year, the company chose what to disclose on its way to listing, and there is still no count of accounts that moved. But it shows the order of events. The losses came first and by design, and the margin turned on the accounts where the deployment work stopped growing faster than the revenue. The filing's own forecast, "We believe that all of our customers will move into the Scale phase over the long term", is a belief. It is not a measurement.

The history before the filing is thinner, and secondhand. Pragmatic Engineer reports that "Up until circa 2016, Palantir had more FDEs than it had 'normal' software engineers" (Pragmatic Engineer, August 2025; T3). A write-up of Bob McGrew's appearance on Y Combinator's Lightcone podcast describes a split between "Echo Teams" of domain experts, "often former military officers or healthcare professionals", and "Delta Teams" of "rapid prototypers" (StartupHub, September 2025; T3, a secondary summary of a podcast). The same write-up places the model in the "product discovery" phase, "where the problem itself is ill-defined". That is the writer's framing, not McGrew's words, but it is the right one: forward deployment is how a company finds out what to build. That is as much Palantir history as this book needs.

What made it pay: the product absorbed the services

A company that sends engineers to every customer and charges for their time is a consultancy. Palantir's margins came from somewhere else, and the clearest account is from Nabeel Qureshi, who joined Palantir as an FDE in 2015 and left in 2023 (Reflections on Palantir, October 2024; T4, one former employee's recollection).

In his account, field engineers did the "cruft work" by hand and product engineers built tools to automate it. Feeding the Product quotes the passage in full. The tools grew into a platform: "now this drives 50%+ of the company's revenue, and it's called Foundry." His verdict: "Palantir pulled off a rare services company → product company pivot: in 2016, descriptions of it as a Silicon Valley services company were not totally off the mark, but in 2024 they are deeply off the mark." That chapter covers how the loop works inside an engagement. The economic point is narrower. The deployment work paid off because it stopped being repeated. Each customer's cruft became a tool, so the next customer's deployment cost less, so the account crossed from Expand into Scale sooner.

Qureshi's answer to the critics, who dismissed the company as "a consulting company masquerading as software, or, at best, a sophisticated form of talent arbitrage", is a margin comparison: "80% gross margins in 2023. These are software margins. Compare to Accenture: 32%." He gives no source for either figure. Treat them as a former insider repeating company-reported numbers, not as an independent check. The same "80% and above" figure reappears in a Chinese think-tank summary of the role (川观新闻, September 2026; T3), and that is an echo, not a second source. The S-1 offers a primary anchor for the direction of travel: a gross margin of 67% in 2019. The trend is real, but the precise 2023 number hasn't been checked here.

Two costs of the model rarely appear in retellings, and Qureshi names both. The first is travel: the habit of flying out first and asking questions later "resulted in out of control travel spend for a long time". The second is pay: "the company paid lower than market salaries, and it was common to stick around for 5+ years." He adds that "most early employees did very well, thanks to the performance of the stock." Part of the early economics was a subsidy from the engineers, paid in salary and recovered in equity. A company that copies the field model without the equity upside is asking for the same subsidy and offering less in return.

Why the labs copied it, and what changed when the product became a model

The labs adopted forward deployment because their first approach failed. Colin Jarvis, who runs forward deployed engineering at OpenAI, describes the years after ChatGPT: "we were able to get customers in production, but it was pretty inconsistent and it took a ton of time every time." What worked consistently "was just sort of embedding with them, understanding their domain really deeply". His conclusion: "our previous hands-off like technical support model was just not reliable getting these folks to production and that kind of led to us deciding to set up a forward deployed model" (Altimeter interview, November 2025; T2, a vendor executive on his own organisation, quoted from the auto-generated captions). That is the same last mile Palantir found: the capability existed, and the customer still couldn't get to an outcome on their own.

The economics differ in three ways, and each one changes what an FDE at a lab is for.

The lab already has a product to sell. Palantir's FDEs were building the platform as they went. A lab's FDE arrives with the model already on sale. A report on OpenAI's deployment arm puts the gap plainly: "Owning model access and having working AI are two different procurement decisions." Most enterprises, it argues, have made only the first (MarketScale, July 2026; T3, relaying the Wall Street Journal). In effect, an engagement that reaches production turns access the customer has already bought into use. That is a different payback from Palantir's, where the engagement often was the sale.

The lab aims at fewer, larger problems. Jarvis says the team targets problems worth "tens of millions sometimes the low billions in terms of value", so that "it's going to have like a big kind of economic impact at the end". He is explicit that he does not see the function becoming "a cast of thousands" (same interview; T4, a statement of strategy, not a measurement). A team sized that way can't pay for itself with fees. It has to pay through what it learns.

What comes back is wider than a tool. At Palantir, the field fed the platform. At a lab it can also feed the model. Jarvis describes splitting the team's capacity "by those two levers": customers chosen to test a definite product hypothesis, and customers with problems so valuable that "there's at least some research learnings here" even if no product follows (same interview; T4, a statement of strategy, not a measurement). His reuse target, quoted in full in Feeding the Product, is the clearest statement of the payback: roughly 20% reusable after the first engagement and 50% after the next two, after which the work moves "into the scaled part of the business". He also says the team is "very much at the start of that journey". It is a target, not a result.

What follows is this book's inference, not a sourced finding. A lab FDE's work can lose its value faster than a Palantir FDE's did. Palantir's field tools became platform features that lasted. A lab FDE's prompt workarounds and model-specific scaffolding may be made unnecessary by the next model release. What lasts is the pattern, the eval, and the description of what the model got wrong. That is one more reason the evals and the field log matter more than the code. Evals and Feeding the Product cover both.

The venture case, and the condition it depends on

The case for copying the model outside the labs was made most loudly by a venture firm. Andreessen Horowitz's "Trading Margin for Moat" argues that the great enterprise software companies started as services businesses: "At IPO, ServiceNow's gross margin was 63.2%, and Workday's was just 54.1% — far below the ideal ~80% for software." By 2024, it says, ServiceNow was at 79% and Workday at 75%. From this it draws a rule for AI application companies: "it's shortsighted to be optimizing for 80% gross margin. The only thing businesses should be optimizing for today is growing total gross profit as fast as possible." It even advises founders to "design incentive structures that allow services to be sold at cost" (a16z, June 2025; T4, an investor's argument). Weigh the source. A venture firm whose business is funding these companies has an interest in investors accepting low early margins. That does not make the argument wrong. It makes it advocacy.

The argument holds only on one condition, and the essay states it: the services have to make the company the customer's system of work, the place where the workflow runs and the data enters. The essay's phrase is "the system(s) of work that generate, capture, and store valuable company data". In its account, once the workflows are established, the incumbents "possess 'moats' that allow them to increase prices and build implementation ecosystems", and the margin follows. Services sold at cost that leave no system of work behind are still services. The margin comes back only when the product absorbs what the engineers did by hand, which is Palantir's lesson again in different words.

Application companies say this to their own staff. A Sierra posting for a strategist on its flagship deployments asks the hire to "manage down cost to serve over time, improving margins" (Sierra posting, September 2026; primary evidence of what the employer asks for, T4 for how the work is done). At an application company, the cost to serve includes your time and the running cost of the agent you build. The wiki's page on agent cost control covers the second part. The first is yours to manage. An FDE whose second deployment of the same pattern takes as long as the first is pushing that margin the wrong way.

2026: services get their own company

In 2026 OpenAI and Anthropic each moved forward deployment capacity into a separate business, with outside investors and its own headcount. The facts are recent and will change, so they are in the box. The argument below does not depend on them.

There are two ways to read the move, and the evidence so far supports both.

The charitable reading: the split protects the lab's own FDEs. If the services work lives in a separate company, the lab's internal team can stay small and pointed at product and research bets. TechCrunch reports that "Anthropic's internal team will continue to focus on strategic, mission-aligned deployments" (T3, a spokesperson's statement). That fits Jarvis's "not a cast of thousands". On this reading, the deployment company is where work goes once a pattern is proven: the "scaled part of the business" his reuse target points at.

The sceptical reading: the trap now has its own company. Jarvis's own warning, quoted in Feeding the Product, is that "the short-term lure of services revenue" drags consulting firms that mean to become product companies back towards services. A separate company with services revenue as its business, and investors expecting a return on billions, is not protected from that pull. It exists to grow because of it. Three details point that way.

• The investors are also the customers. "The private equity firms backing Ode will funnel their own portfolio companies to the joint venture as potential customers" (TechCrunch, T3). ERP Today describes DeployCo's backers as "a consortium of private equity and institutional firms". A captive pipeline lowers the cost of acquiring customers. It also means demand is partly arranged, not purely earned.
• The ambition is sized like a services market. Ode's chief executive told TechCrunch: "It's pretty easy to imagine this as a trillion-dollar company someday if we execute well." His own worry is "how do you go through that phase of hyper growth without losing the emphasis on quality?" (T3). That is the question every consultancy faces as it scales.
• The competitors are consultancies. TechCrunch names "consulting giants like Deloitte and Accenture, which have created their own FDE teams" as Ode's competition. When the large IT services firms adopt your title, the title no longer tells anyone you are not one of them.

Watch three things. Does field work flow back into the labs' products and models, or stay with each customer? Do the deployment companies report outcomes, or only headcount and funding? And do their engineers do the work this book describes, owning the outcome from discovery to handoff, or staff augmentation under a newer name? As of October 2026 no public evidence answers any of the three. Both companies are months old, and DeployCo was still choosing its first customers at the time of the July report.

The sceptics, taken seriously

Most writing about the role comes from employers hiring for it and people selling courses. The sceptical view deserves the same hearing. It comes in three forms.

"It's consulting." This was the standard charge against Palantir, in Qureshi's own report of it: "a consulting company masquerading as software" (T4). Palantir's later margins answer the charge for Palantir. They answer nothing for any other company. Each employer has to show its own loop back to product, and the S-1 table shows how long that took even at the company that succeeded: years of losses on accounts that were not yet self-sufficient.

"Engineers don't want it, or regret taking it." What an FDE Is, and Isn't sets out this evidence, a recruiter's guess and two disappointed hires, and none of it is a measurement. The economic reading this chapter adds is that this is what the job becomes when an employer sells FDE time and keeps none of the learning, and engineers notice it before the financial statements do.

"The numbers are weaker than they look." This one is the book's own, and it applies to this chapter. The strongest economic evidence for forward deployment is a company's own filing about itself, and its headline figure is a top quartile selected by margin. Nobody has published how many Acquire-phase customers reached Scale. No lab has published the unit economics of its FDE team, how many engagements reached production, or what the reuse rate turned out to be. The deployment companies have announced funding and headcount, not outcomes. The model is plausible, and Palantir's history shows it can work. Whether it works for the company that is hiring you is a question about that company, and the public record can't answer it. What an FDE Is, and Isn't takes the definitional half of the sceptics' case, the claim that much of what is called FDE work is something else.

China: the job family tells you who pays

In China the economics show up somewhere unusual: in which job family an employer files the role. That decides which budget pays for it and which manager judges it. What an FDE Is, and Isn't gives the filings from an iFanr article republished by 36Kr: Tencent's 前线部署工程师 posts in product, ByteDance's in R&D, and ByteDance's FDE internships under sales support (iFanr via 36Kr, August 2026; T3). One company, two classifications. The same title can be a product investment or a cost of sale, depending on the requisition.

The same article states the economic tension directly: "Software companies aim to build once and sell many times, while the FDE puts expensive engineers back into every customer project" (软件公司追求一次开发、重复销售，FDE 却把昂贵的工程师重新放进每一个客户项目). Summarising Tencent's posting, it lists three or more years of engineering or "toB 交付" (enterprise delivery) experience as the usual bar, so an enterprise delivery background counts as a route into the role. A practitioner interviewed by 中新经纬, who had worked as an implementation engineer (实施工程师), in pre-sales, as a product manager and as a project manager, describes the new role as one that "brings together pre-sales, product and project" (这个岗位刚好整合了售前、产品、项目三个环节) (中新经纬 via 36Kr, June 2026; T3, one interviewee under a pseudonym). That is a fair description of the job. It also shows the risk: a role that merges pre-sales, product and project can drift back to any one of the three.

On the market's shape, the evidence is a forecast, not a measurement. An FDE industry report by the think tank 霞光智库, summarised by 川观新闻, says the Chinese market is currently driven mainly by in-house teams at ByteDance, Alibaba and Tencent, that external professional services are still early, and that it expects outward delivery to accelerate after 2027 as the large firms productise their capabilities (川观新闻, September 2026; T3, relaying a report whose method is not given). The same summary repeats the Palantir 80% margin and the 643-to-5,330 US job-posting figures, both echoes. If the forecast holds, China will reach the deployment-company question later than the US, and from the opposite side: the platforms productise first, and services spin out afterwards. Chinese titles and pay are covered with the rest of the career evidence in Part IV, in the Where FDEs Work chapter.

Read your employer's model before it reads you

You can't change your employer's economics, but you can find out what they are before they surprise you. Five questions do it, and the answers are usually available in the final interview or the first month. Ask them in these words. How a hiring manager answers is itself evidence.

The decision rule: if three or more answers land in the right-hand column, you are being offered a services job. Judge it on services terms (pay, utilisation targets, travel and the exit path), not on product influence it can't give you. The answers also place your employer in one of three economic models. Real companies mix them, but every one leans towards one, and the lean tells you what your work is for and which trap to watch.

None of the three is the wrong place to work. They are different jobs under one title, and the skill map in the next chapter will look different depending on which one you are in. The mistake is to take a job in one model while expecting the career of another.