FDE or Outsourcing Is the Wrong Question.

"Forward-deployed engineer" has become the most valuable job title in software. Everyone offering one gets asked the same question — how is this different from outsourcing? — and nearly everyone gives the same answer. An FDE company has a product. The engineer in your office is there to deploy it and extend it. An outsourcer just sends you people.

I have spent twenty-five years running a company that sells engineers' time rather than a product — the thing the FDE pitch defines itself against — so I have an interest in this. But I think the answer is wrong in a way that is worth taking apart, because it tells you who drew the line.

Whose line it is

The product-versus-people distinction is a valuation distinction. A company whose engineers deploy a product earns revenue that repeats at low marginal cost: the second customer costs less than the first, the hundredth costs almost nothing. That supports a multiple. A company that bills hours earns revenue that scales with headcount and stops when the people go home. That supports a salary. Investors prefer the first, and they are right to — from where they sit, it is arithmetic, not cynicism.

But it answers one question directly — what is this company worth? — and the client's question only by assumption: that what is good for the platform will also be good for you. Most of the time it is. The interesting cases are the ones where it isn't.

What the client gets

Change seats. You are the client, and an engineer is sitting in your office. The thing that matters most to you is not their title. It is what they are loyal to.

If their employer has a product, part of their job is the product. Every problem you bring them is looked at twice — once as your problem, once as an opportunity to extend the platform. Often the two coincide; that is why the model works at all. When they don't, the platform has the stronger claim on the engineer's time, and you find that out late. The roadmap has to be served. The module that would make you a reference customer gets built before the one you actually need. The problem that doesn't fit the platform gets reshaped until it does.

Reusable software is an asset on the vendor's balance sheet. On yours it can be a constraint: it decides what shape your solution is allowed to take before anyone has looked closely at your business. The engineer deployed to you is capable and well-meaning and still cannot help it. Their best work for you is also work for the product, and the product is what their employer is paid for.

An engineer with no product to defend has one thing to serve. That is what consulting is, when it is done honestly: a person's judgment pointed entirely at your situation, with nothing in their bag they need you to buy.

Where this argument has to give ground

None of this is an argument against products. Most of what any business runs on should be bought, not built — accounting, email, payroll, the database. Building those yourself is not independence; it is a hobby with a payroll. Reuse is how software got cheap, and clients should want as much of it as they can get.

The useful question is where your business is different from everyone else's. There, you want code that answers to you. Everywhere else, buy. A good engineer in your office will tell you which is which — including when the honest answer is "buy something and don't pay me to build it." An engineer whose employer sells the something can give that advice too. They just can't give it as freely, and you can't be sure when they are.

What it costs to be on the other side

Working without a product to amortise means a company has nothing to sell except its engineers' time and judgment, and no way to hide what it charges for them. We decided to make that visible instead: of every engineering dollar, 70% goes to the engineer doing the work, 10% to the Account Owner responsible for the client, 20% to the company, and the split is on the invoice. We are not asking for a multiple. We are asking to be paid for the thing the client is actually buying, and to show them that's what they paid for.

The hard part is the engineer

Here the argument turns on the people on my side of the table.

Palantir, where the FDE title comes from, split the role in two from the beginning: Deltas, who build, and Echoes, who sit in the client's business and work out what is worth building. The split made sense when building was the scarce skill. It isn't any more. AI has taken a large share of the building, and what is left for a programmer is the Echo's job — which most programmers have never done.

That is the real cost of the position I am taking. If you don't have a product to deploy, the engineer is the product, and an engineer who only knows how to turn tickets into code has nothing left to sell. The one route open is into the client's business: understanding it the way its CEO does, and finding the software that makes the most difference to it. Not a career suggestion. It is the line between programmers who will have work and programmers who won't, and we spend most of our effort now on getting our own people across it.