FDE vs outsourcing: where the line actually is

In one line: outsourcing sells capacity and features; forward deployed engineering sells judgement and a reusable method. The dividing line is not whether anyone sits on your site — that is only a working arrangement — but what your organisation is left holding once the project ends and the people leave.

That sounds abstract, but in a purchasing decision it maps onto three concrete questions: what your money bought, who carries the project risk, and whether the second, similar project costs you the same again.

Three tests

Test one: what remains when the project ends

This is the most widely used dividing line in the industry today:

What remains when the project ends	What that is called
A system that runs, and knowledge that leaves with the people	Outsourcing
Knowledge that came back but cannot be reused — the next client starts from zero	Project delivery
Domain knowledge, stripped of customer information, turned into reusable components, connectors and templates	Forward deployed engineering
Delivery cost for the next similar client drops measurably	Forward deployed engineering at scale

The load-bearing phrase is “stripped of customer information”. What gets reused is the general method and components, never your specific business rules, data or system detail. That boundary has to be written into the contract — a verbal assurance that “we won’t use your data” is worth nothing.

Test two: verify by workload, not by claims

A quantified principle from Bob McGrew, formerly of Palantir:

If the first client takes ten person-months and the tenth client in the same industry still takes ten, the model has not worked.

The value of this test is that it cannot be answered vaguely. Ask any candidate provider: how much work did your first client in this industry take, and how much did your tenth? If the two numbers are similar, the firm is not compounding — you are paying for time, with no method included.

A second red line often cited: if a single client permanently consumes 30–40% of delivery capacity, the business has quietly become high-end staff augmentation. (The figure comes from F-Prime.)

Test three: look at the unit being priced

This one is most often overlooked and most revealing:

• Priced by the person-day or person-month → you are buying time. In that arrangement the provider’s interest runs against the project finishing sooner.
• Priced by a feature list → you are buying implementation. The requirement must already be clear, or the list itself becomes the dispute.
• Priced by phase and scope → you are buying an outcome. Scope is defined, acceptance criteria come first, and each phase can be stopped.
• Priced against a business indicator → you are buying an effect. Theoretically ideal, extremely hard to define, and prone to argument in practice.

An honest caveat: none of these is inherently better. For a fully standardised, clearly bounded piece of work, buying capacity by the day is the most economical option. The problem is not which model is more advanced — it is whether the provider tells you which one they are selling.

Seven questions to ask any provider

These work on any candidate. They are designed so that the answers have to be specific enough that they cannot be improvised.

1. “How much work does your first client in this industry take, and how much does your tenth?” This tests compounding. A vague answer is usually “every client is different” — true, but using it to avoid an order-of-magnitude judgement means there is no accumulated method.

2. “When the project ends, what remains besides the system?” A good answer names specific reusable assets: components, connectors, templates, evaluation sets. If the answer is “full documentation”, note that documentation is part of delivery, not compounding.

3. “Give me an example of a client you advised against working with.” A provider that has never talked anyone out of a project either screens extremely hard — which is a good sign — or takes everything.

4. “Who sets acceptance criteria, and when?” If acceptance is to be discussed at handover, the project will most likely end in an argument. The industry describes the pattern plainly: the client says “change this bit” or “the results still aren’t there”, and acceptance slides indefinitely.

5. “Who will actually be assigned, and what have they done like this before?” Ask about individuals, not the firm’s credentials. Delivery quality depends heavily on the person. Also note: “we’ll decide the team after kick-off” is a warning sign — it suggests you were sold by a pre-sales team while a different team delivers.

6. “How is our data used? Does it end up in work you do for other clients?” This is the boundary of compounding. A serious answer lands in contract clauses: the scope of access, the identity used, how it is audited, which data must not leave your environment, and what happens to it afterwards.

7. “Who owns it after launch, and how fast do you respond when it breaks?” Many AI projects die in the three months after launch: model drift, shifting data distributions, changed business rules, and nobody responsible. Delivery without a named owner is incomplete.

When you only need outsourcing

This is the point of the article: forward deployed engineering is not a more advanced form of outsourcing. It suits different problems.

In these cases, ordinary outsourcing or simply buying a product is the better call:

• The requirement is already standardised. You know what you want and a mature product covers it — buying is cheaper and faster than building.
• The requirement is already clear. If you can write a specification a developer can follow directly, what you need is development capacity, not an FDE.
• You want stable long-term execution capacity. Ongoing iteration, maintenance, testing. Buying that by the day is the most economical arrangement.
• You already have someone who can decide what to build. If somebody in your organisation can state clearly what to build, to what standard, and who signs it off, then the core value of an FDE — judgement about the use case — is not scarce.

Conversely, an FDE earns their keep precisely when the requirement is unclear. One practitioner put it well: if a customer could state exactly what they wanted, they probably would not be looking for an FDE.

One risk that is easy to miss

A final warning that matters particularly in the Chinese market: the more beautiful the promise, the more carefully it should be examined.

The classic failure mode in AI deployment is a project that scores well on technical metrics and is rejected by the business. The demo works; real data does not. Or efficiency improves while profit does not. One practitioner described the gap vividly: a department produces a thousand extra documents a month, and to the boss it looks like a larger compute bill and nothing else.

The test is simple — ask the provider to write their commitment in a form that is measurable, reproducible, and usable as an acceptance criterion. Any commitment that can only be phrased as an adjective (“significantly more efficient”, “substantially lower cost”) will become an argument at acceptance.

---

The line is drawn. What remains is which side your own situation falls on. You may want to read What is a forward deployed engineer? and When does a company actually need an FDE?, or simply talk to us — and if the answer is that you only need outsourcing, we will say so.