FDE 101

I gave the FDE 101 talk to a thousand AI engineers. It's a design partnership that scales into enterprise and never ends.

Last month I stood on a stage at the AI Engineer World’s Fair and gave a talk on forward deployed engineering to a thousand AI engineers.

Here’s the whole thing: where FDE came from, why Palantir bet its entire go-to-market on it, the two questions to ask before you build one, and why I think a lot more of you are about to need one whether you planned on it or not.

Look at public SaaS companies and measure them by average contract value, meaning how much a given customer spends with you in a year.

Palantir is first, at around $4 million. Next is ServiceNow at $1.2 million. Then Workday, around $800K. And then there is not a single public SaaS company that even cracks half a million

Look at where the cliff is. Snowflake is next at $322K, then Salesforce at $252K, Azure at $214K, and it keeps falling from there. Palantir isn’t leading this list. It’s playing a different game than everyone on it.

Palantir builds a platform called Foundry. It lets an organization of any size centralize its data and build an ontology on top of it. What that really means is turning your data into proper nouns. Instead of table one, table two, table three, you have a single source of truth called “warehouses.” Then you build applications on top.

Genuinely powerful. But say that to a leader in industry and you’ll get: cool, you’ve made my data organized. What does that do for my actual business?

And they’re right. That’s where selling pure technology falls short.

There’s a second problem, and it’s worse. If you sell an app-building platform, your success is determined by how well your customers can use your software. So they pay to buy the platform, then pay again to train their people up on it, and only then can they build anything.

That is a terrible way to do business.

What Palantir figured out is that you stop selling services, you stop selling products, and you sell both as one thing. The customer isn’t buying software. They aren’t buying somebody’s hours. They’re buying an outcome. You send really smart people who go understand the customer’s business, build them a solution on the platform, and deliver the result.

If you run CPG, you care about shelf placement and sales throughput. You don’t care how the data is organized, and you shouldn’t have to. That’s an implementation detail.

Here’s the thing I want to be clear about, because sending engineers to the front line is a genuinely strange idea. Software engineers, me included, are some of the last people who should be customer-facing.

So it comes down to two things: how technical is the thing you sell, and how technical is the person buying it.

• Technical product, technical buyer. GitHub, Datadog. Your users are software engineers. They can absorb that complexity, because it’s their job. You don’t need FDE.
• Configurable product, non-technical buyer. Rippling, Jira, Slack. Those tools might be complicated, but they aren’t meant to be built on. You don’t need FDE.
• Technical product, non-technical buyer. This is the only box that needs FDE, and it is exactly the corner Palantir found itself in.

Why was that Palantir’s problem specifically? Because Foundry is an app-building platform, which makes it inherently less interesting to Google or Meta or the labs. They have great engineers. They’ll build whatever apps they need.

But sell to a Fortune 500 company in oil and gas and that engineering depth isn’t there. Their pipelines aren’t data pipelines.

So you have two options. Trust that they’ll invest the years to get good at your platform. Or say: here’s the setup, we’ll loan you excellent engineers you don’t have to hire, recruit, manage, or retain. They know this platform cold, and they’ll work with you the way a waiter at a fine dining restaurant works. Figure out what you actually need, then go build it.

That’s how Palantir went to market with the global Fortune 500. The numbers above are how it turned out.

If you’ve been at an early-stage startup, you already know this motion under a different name.

In the early days you don’t know what your product is and your customer doesn’t know what they’re buying. So you say: let me work with you closely, I’ll spend my time and my energy and my resources, you give me the context on your problem, and I’ll build you something good. That’s how most B2B startups find product-market fit.

FDE is that, scaled into the enterprise. That was Palantir’s core assertion. Who decided design partnerships were only for the first eighteen months of a company?

Now, the smart people in the audience always push back here, and they’re right to. You can’t do that in enterprise, because you can’t maintain it. Build something custom for every single customer and you’re herding cats across a pile of terrible code. No engineer will work for you. Nobody wants to learn 55 repos.

Correct, if every FDE is building from scratch.

And this is the part I want to say as plainly as I can. If you stand up an FDE function where each FDE builds from scratch, you do not have an FDE function. You have a dev shop.

Nothing wrong with dev shops. They’re profitable businesses. But it’s a different company than the one you think you’re building.

What makes an FDE program different is that FDEs build on top of a platform. They never write software from scratch. There’s already a set of primitives, and the job is assembling them into an application, a workflow, a solution that’s arbitrarily valuable to that customer.

Miss this and you reinvent the wheel again and again until your P&L eats you alive on maintenance costs, assuming your engineers don’t all quit first.

When people ask me how to bring this back to their org, I give them two questions.

First: do I need an FDE function, not want one?

It’s easy to want things that are in vogue. The real test is whether you have some corner of your business where you must take a technically complicated thing to market with a non-technical buyer. If you don’t have that situation, FDE probably isn’t your answer. There’s great work to be done with DevRel and developer engagement if your motion is technical, and great work in a sales-led motion if you’re doing more traditional SaaS.

Second: do I have a platform, or am I willing to invest in building one?

However tempting it is to have engineers who directly generate revenue: if they aren’t building on shared primitives, you are in for a very bad time. I can’t overstate the maintenance burden this creates even when you do have a robust platform. Without one it’s fatal.

Palantir came to market around 2004. Obviously AI has since made it much easier to write code, and much easier to build sophisticated customizable software for customers. How many of you are building agents for insurance, for legal, for whatever vertical? I don’t even need to see the hands.

But that’s not the interesting change, and here’s my actual hypothesis.

The world did not suddenly wake up and recognize that Palantir’s FDE motion was a good idea. What changed is the nature of doing business in software itself. Nearly every platform is now agentic. Which means nearly every platform is now customizable. Which means nearly all of you are heading into a situation where your customers have no idea what your product actually does.

And if you leave the success or failure of your product in their hands, dependent on their ability to implement it, that is not going to be a comfortable motion when you try to move up-market, or expand horizontally, or expand vertically.

Put another way: AI is quietly pushing a lot more companies into that third box. Most of them haven’t noticed yet.

How atomic should the shared primitives be?

Very lawyerly answer: it depends on your user base. There are plenty of industries where you can get away with robust primitives, where the app is 60% built and customers customize the other 40%. There are others where that’s completely inappropriate and you need extremely granular tooling.

The example everyone knows is AWS. Most of you are good enough engineers that you could buy server racks and get them online and maintain them. But who’s done that since the 90s? AWS gives you shared primitives like DynamoDB, so you’re not inventing a database from scratch, precisely because they’re serving an enormously broad set of customers.

Should more than one FDE work an account?

Strongly encouraged. When you’re doing custom work for a customer, the last thing you want is a single point of failure where one person holds all the context, goes on vacation, and you’re screwed.

What goes on the platform versus the forward deployed side?

Anything bespoke and unique to one customer should stay with that customer. Anything generalizable should get generalized over time. Early on you won’t have many primitives, and that’s fine. FDE is also a fantastic way to scout ahead and find which product investments are actually worth making.

What’s the perfect FDE profile?

This is the tagline I left them with: an FDE is nothing more than a customer-facing software engineer. Someone you’d hire as an engineer on your team, who you’d also trust in front of a customer. The rest you figure out as you go.

That’s the 101. If you’re sitting on a platform that’s getting more agentic by the quarter and a customer base that can’t quite figure out how to use it, you already know which box you’re in.