Delivery

Forward Deployed Engineering: New Packaging, Same Bill?

  • Author Delivery Team
  • Published on October 1, 2026
  • Read time ~ 6 min read

FDE is having a moment. Almost none of the invoices have caught up.

Forward Deployed Engineering has become the label of the year in software delivery marketing. Say it in a pitch, and you signal something modern: engineers embedded with the client, close to the problem, accountable for outcomes rather than hours. 

But labels are cheap, and relabeling a contract costs nothing while changing the risk and payment structure behind it does.

A GoodFirms survey of 133 firms, cited by Idealogic, found that only 3.6% of them bill in the classic Time & Materials model. That sounds like proof the market has moved on, but the number alone doesn’t prove it.

So the question worth asking isn’t whether a vendor calls what they do FDE. It’s whether they’d pass their own test if you asked them to.

That test starts with where the term actually came from.

Where the term actually comes from

FDE didn’t start as a sales term. It started at Palantir, around 2005, as “Deltas”: engineers placed directly inside client organizations like the CIA, NSA, and the US Army, working on the actual problem instead of a spec handed down through three layers of management. 

The public record doesn’t detail how those contracts were billed. What survives is the spirit of the role: 

  • embedded, close to the problem, 
  • on the hook for whether it actually works, not just for showing up.

That spirit is where the confusion starts. 

A chunk of what’s published about “FDE” in 2026 has nothing to do with buying delivery services at all. It’s about how product companies like Palantir or OpenAI pay their own internal FDE employees. That’s a compensation question inside one company.

This article is about something else entirely: what a client should expect when a vendor sells them “FDE” as a delivery model.

Mixing the two up matters: a Palantir engineer’s internal pay structure is one thing, what a vendor promises you as a paying client is another. Blur that line, and FDE sounds like an established, well-defined buying model. On the buyer side, it isn’t – not yet.

Why this isn't just semantics

Here’s the trap: changing the invoice format isn’t the same as changing what you’re paying for. 

A vendor can swap hourly billing for a flat monthly fee and call it FDE, but if that fee still buys time and availability, not a result. Nothing structural has changed. 

An “unlimited engineering capacity” subscription looks modern on paper. It’s still a clock running in the background.

The distinction that actually matters is simple: is payment tied to an outcome, in any form, or is it tied to time?

The invoice format is a distraction from that question, not an answer to it.

The commercial test: is payment tied to outcome?

This is the part that you as a buyer can actually act on. Before signing anything labelled “FDE,” ask three questions:

  • Billing model: is there any measurable success condition that affects payment, regardless of the format (T&M, subscription, retainer)?
  • IP ownership: who owns the code once it’s built?
  • Exit clauses: how easily can you end the engagement if it isn’t working?

The data from the aforementioned GoodFirms survey gives a useful map of where the market actually sits:

  • Time & Materials: 3.6%
  • Fixed scope: 7.1%
  • Retainer tied to jointly set OKRs: 10.7%
  • Purely outcome-based: 21.4%
  • Folded into a broader enterprise contract: 25%
  • Hybrid models: 28.6%

As the report puts it: “Time and materials, the billing model that defines staff augmentation, is used by 3.6%.” That’s not a niche anecdote. It’s a market that has largely already moved past the model FDE is supposed to replace, at least on paper.

Retainer pricing across the wider market sits in a similar range: roughly $8,000-$25,000 a month for an embedded engineer on call and on cadence. And per the same GoodFirms survey cited above, 78.6% of companies already tie FDE success to pre-agreed business outcomes, not hours logged – so the billing format matters less than whether that condition exists at all.

And a useful piece of honesty comes from AY Automate– a staffing platform that markets its own offering as FDE. Their CTO – a former IBM engineer – has openly said the company gets paid for placing an engineer, not for the outcome that engineer delivers.

That’s worth paying attention to: even vendors marketing themselves as “FDE” don’t always pass their own test.

The lock-in test: can you leave?

There’s a second test, separate from billing: can you leave?

A genuine FDE engagement shouldn’t leave you dependent on the vendor’s proprietary AI tooling to keep the thing running after they’re gone.

The shipped code might run fine on its own – what doesn’t is changing it. If every fix, feature, or integration still has to go through the vendor’s proprietary prompts, fine-tuned agents, or internal tooling, the outcome-based invoice is decoration on top of the same lock-in staff augmentation always risked – just with better branding.

Where the overhead actually lives

Forget the label for a second: the real cost in a normal engagement almost never comes from the hourly rate.

It comes from:

  1. team size, 
  2. how many people you need in the room before anything ships, 
  3. the weeks a new hire spends just catching up to what the client already knows.

I’ve seen this shape repeat, both in our own delivery work and in the RFPs that land on our desk. The pattern shows up across clients, not just one:

The larger the team, the slower the work.

And that’s where the FDE model can be a great alternative.

Put someone genuinely embedded with the client, hand them AI tooling that cuts down on translating between roles, and the team you need shrinks, not because anyone works more hours, but because nobody’s spending half the week explaining the problem to the next person.

Smaller team, faster results.

Before you sign an FDE contract: the checklist

Before you sign a contract that calls itself “Forward Deployed Engineering,” ask the vendor directly:

  1. What measurable condition, if any, ties our payment to a result, not just to time or availability?
  2. Who owns the IP once the engagement ends?
  3. How do we exit, and what do we lose if we do?
  4. Does the outcome depend on tooling we don’t control and can’t take with us?

If those answers sound like a standard staff-augmentation contract wearing a new cover page, you already have your answer.

The bottom line: FDE as a label means nothing on its own. What matters is whether payment is tied to outcome, who owns the code, and how easily you can walk away: three questions worth putting to any vendor before you sign, as an actual conversation, not paperwork.

You might also like