# Forward Deployed Engineering 101 — Kevin Bai, Anthropic, ex Palantir & Rippling Founding FDE AI Engineer · 2026-07-28 Kevin Bai of Anthropic, formerly at Palantir and Rippling, argues that Forward Deployed Engineering (FDE) is the go-to-market motion for selling highly technical platforms to non-technical buyers, as Palantir did with its Foundry platform. The key is not building bespoke solutions from scratch but assembling outcomes on a reusable platform of shared primitives; otherwise it becomes a dev shop. FDE targets a specific quadrant: complex product + non-technical buyer, exemplified by Palantir's $4M average contract value vs. ServiceNow's $1.2M and Workday's $600K. Two questions determine need: is your product complex enough to require hand-holding, and do you have engineers who can carry that? AI has made building easy and nearly everything agentic, pushing FDE toward the center of software sales. ## Questions this episode answers ### What is forward deployed engineering and how did Palantir use it to land large enterprise deals? Kevin Bai explains that FDE is selling an outcome by embedding engineers who build a solution on your platform for non-technical buyers, rather than selling just a product or service. It's like scaling design partnerships to enterprise, avoiding custom one-offs by using a shared platform. Palantir used this to achieve average contract values of $4M, far outpacing other SaaS companies. [3:03](https://aiengineer.podhood.com/df343e9b-db21-4485-9949-9b3bd4654f0f?t=183000) ### How much larger were Palantir's contract values compared to other SaaS companies? At the time, Palantir's average contract value was $4M, number one among public SaaS companies. The next closest was ServiceNow at $1.2M, Workday at $600K, and no other public SaaS company even reached $500K. This demonstrated the effectiveness of the FDE model in landing high-value contracts. [6:53](https://aiengineer.podhood.com/df343e9b-db21-4485-9949-9b3bd4654f0f?t=413000) ### When should a company consider building a forward deployed engineering team? Kevin Bai says you should ask two questions: first, do you need to sell a technically complicated product to a non-technical buyer? If your buyer is technical or your product is simple to configure, FDE isn't necessary. Second, do you have a platform of shared primitives for engineers to build on? Without a platform, you end up with a costly, unmaintainable dev shop. [9:48](https://aiengineer.podhood.com/df343e9b-db21-4485-9949-9b3bd4654f0f?t=588000) ### How has the rise of AI and agentic platforms changed the need for forward deployed engineering? According to Kevin Bai, since Palantir's early days, AI has made building and customizing software dramatically easier. Now nearly every platform is agentic and customizable, meaning more companies are selling complex, adaptable tools to non-technical buyers. This pulls the FDE motion—once a niche—toward the center of how software is sold, as leaving implementation to customers becomes riskier. [11:29](https://aiengineer.podhood.com/df343e9b-db21-4485-9949-9b3bd4654f0f?t=689000) ## Key moments - **[0:00] Intro** - **[1:47] Palantir's Platform** - [3:03] Palantir's FDE model sells an outcome, combining its software platform with deployed engineering services. - **[3:14] Solution Selling** - [4:04] FDE is necessary only when selling a very technical product to a non-technical buyer. - **[4:18] Technical Buyers** - **[5:59] Business Case** - [6:53] Palantir's average contract value is $4M, vs ServiceNow's $1.2M and Workday's $600K; no other SaaS company cracks $500K. - **[7:16] Platform Primitives** - [7:47] FDE scales the startup design partnership model into the enterprise. - [8:44] An FDE program requires engineers building on a reusable platform; custom work from scratch is a dev shop. - **[9:48] Starting FDE** - [10:39] To start FDE, ask: Must you sell something technical to a non-technical buyer? And do you have a platform? - **[11:34] Agentic Shift** - [12:10] AI has made nearly every platform agentic and customizable, pulling FDE motions toward the center of software sales. - **[13:08] Q&A** - [13:23] Q: How atomic should shared primitives be in an FDE platform? - [15:06] Q: Can FDEs from two different companies collaborate effectively? - [16:11] Q: When should a change be made on the platform vs kept as custom work? - [16:59] Q: What is the ideal profile for a Forward Deployed Engineer? ## Speakers - **Kevin Bai** (guest) ## Topics Developer Tool GTM ## Mentioned Anthropic (company), Palantir (company), Rippling (company), Foundry (product) ## Transcript ### Intro **Kevin Bai** [0:16] Allright, thank you so much, Basil, for the introduction. Hello there, those of you in the audience, thank you so much for joining us today. My name is Kevin. Uh, technically we don't really have titles, so I am member of technical staff at Anthropic, working on the Applied AI team. Before this, I joined Rippling to help build their FDE function. I was the first person to join that team, and we grew it to around 25 in a year, and so that's pretty cool. And then before that, I did a bunch of stuff at Palantir. But, you know, lists of companies are not really that interesting,right? Because we're talking about a function, and what I hope you're all here for is to hear about Forward Deployed Engineering. If you are here for evals, or if you're here for, I don't know, videos of kittens, that's probably one room over. I'm also not qualified to talk about those things, so I am trying to give a talk to you on Forward Deployed Engineering 101. So what I want to do is walk you through the history of the role, the nature of the function, why Palantir chose to adopt FDE as its go-to-market motion, and then,right, extend that to maybe how you could apply it to your own organizations and businesses. And if possible, at the end, I would love to take any and all questions. Allright, does that sound good? **Guest** [1:36] Yes. **Kevin Bai** [1:36] Yeah? Okay, that's too low energy. Does that sound good? **Guest** [1:39] Yes. **Kevin Bai** [1:40] There we go. Oh my God, it's a conference, not a funeral. Let's go. So, okay, high level,right, what does Palantir do? Palantir is a technology company that creates a technology platform, a software platform called Foundry. What Foundry does is Foundry enables organizations of arbitrary size to centralize all of their data in one place to create an ontology. ### Palantir's Platform **Kevin Bai** [2:09] What that means is to create proper nouns out of their data so that instead of having, you know, table one, table two, table three, if you have warehouses, you have a single table that's the source of truth for warehouses. And then on top of that, Foundry enables companies to build applications. Okay, so if I was to explain that to some industry leader or other, they would be like, "Cool, you've made my data organized, but what does that do for my actual business?" Right? And so that's kind of where it falls short if you're just selling technology. And then the other piece that's kind of interesting,right, is that you, as a app-building platform, Foundry, your success is determined by how well your customers can use your particular piece of software. And so there's also a huge tax,right? Not only are customers paying to invest in this platform, they are also needing to train up their people to get effective on it, and then, and only then, are they able to build things. That is a terrible way to do business, and we soon realized that instead of selling just services or just products, you sell both. So it's one combined thing where the customer is neither buying a piece of software nor are they buying the time of someone, they are buying an outcome,right? ### Solution Selling **Kevin Bai** [3:21] You are sending over really smart people who will go and understand the nature of the customer's business, build them a solution on top of this platform, Foundry, and then the thing that you get in the end is that outcome. Because if you are a leader of industry,right, if you're working in CPG, you care about, you know, getting more placement on the shelves, or you care about higher throughput of sales, you don't really care how the data is organized, and nor should you care,right? That's more of an implementation detail. So where does this notion come from, this ridiculous idea of, like, sending engineers to the forefront? Because I'm pretty sure of all the folks in the audience, you know, if you're familiar with software engineers, myself included, we're some of the last people that should be customer-facing. And so I want to make this, like, really, really clear, okay? You can imagine this as a Punnett square. It has to do with what it is you're selling and then who it is that's buying from you. So if you sell a very technical platform or product,right, let's forget Foundry for a second. ### Technical Buyers **Kevin Bai** [4:21] If you sell a GitHub or if you sell a Datadog, it is an incredibly complicated piece of software. However, your ICP,right, are going to be CTOs, CIOs, and then your users are going to be software engineers. They're going to be people who can take and absorb this complexity and use it because it's part of their job. The other situation is you are selling something that's not that complicated, and your buyer is not that technical, which is also fine,right? Say you have a tool, something like a Rippling or something like a Jira or like a Slack, and those tools might be complicated, but they're configurable. They're not meant to be developed upon. And so it's fine to be selling to a non-technical buyer. You only need FDE if you are in this weird, unique situation of Palantir where you are having to sell something very technical to a non-technical buyer. Now, historically, why was that the case? You know, like, didn't Palantir like to do things easier than that? Well, it's because the nature of Foundry,right, which is an app-building platform, makes it inherently not as interesting to the large tech companies. Google, Meta, what have you, these days, the labs, they all have great software engineers, and they can build whatever apps the organization needs. But when you're selling to, say, you know, a Fortune 500 client that works in oil and gas, they're not really going to have that kind of engineering depth,right? Their pipelines are not data pipelines, it's more going to be, you know, fluorocarbons or something like that. So for them to really get full value of your platform, you could either trust that they'll spend the time to, you know, not only buy your platform and use it, or you could just say, "Hey, here's the setup. ### Business Case **Kevin Bai** [6:01] We will loan you some really good engineers that you don't have to hire, recruit, manage, or retain." They will be trained in not only how to use this platform, but they will also, you know, work really closely with you in the same way that if you were at a fine dining restaurant,right, the waiter is there to cater to your every need, and they will figure out how to solve you the problem and then build you the software. And so that ended up being the way that Palantir went to market with the Fortune 500, with the global Fortune 500, and how has that turned out,right? Because there's no point in me just getting on stage saying, "Oh, this is so cool. You know, here's the details, blah, blah, blah." So I'll give you some numbers. If you look at the public SaaS companies in the Fortune 500 and you measure them by ACV, average contract value, so, you know, of any given customer, how much money is that customer spending with that particular vendor? Palantir is first at 4 million, last I checked. Next biggest is ServiceNow at 1.2. Next biggest, I want to say, is Workday at 600K. And then there is not a single public SaaS company that even cracks half a million ACV. So just by these numbers, I would say it works pretty well. Palantir is at some ridiculous valuation now, only at a few thousand headcount. So, okay, what is this FDE thing? What is this model? What does this mean? ### Platform Primitives **Kevin Bai** [7:22] Do we have any startups in the audience or anybody working early stage? Yeah? Okay, some hands. So I'm sure you're familiar with the concept of a design partnership. So in the early days of a startup, when you don't know what your product is and your customers don't know what they're buying, you say, "Hey, let me work with you really closely. Let me figure out what it is you need. I will, you know, spend my time, my energy, my technology, my resources. You just give me the context on what your problem is, and I'll build you a really good solution." That's generally how most startups, at least in the B2B segment, find product-market fit. FDE is basically taking this concept of a design partnership and scaling it up into enterprise,right? That was the core assertion of Palantir, was that who said, who said that design partnerships were only for the beginning stages of a company? Why can you not just do that at scale at enterprise? Well, some of you in the audience who are very smart and observant might say, "Kevin, you can't do that in the enterprise because you can't maintain it. If you build something custom for every single customer, you are going to be herding a whole bunch of cats, and you're going to have, you know, a bunch of really shitty code, and no engineer is ever going to work for me because they can't maintain it, and no one wants to learn 55 repos." And you would be totallyright. If you were to implement an FDE function where each FDE is building entirely from scratch, my friends, you do not have an FDE function, you have a dev shop. Nothing wrong with that, of course. Those are really profitable businesses. But the thing that makes an FDE program different is that they are building on top of a platform. They are never writing software from scratch,right? There is already a set of primitives on top of which they could assemble them into some application, some workflow, some solution that is arbitrarily valuable to their customers. That is kind of the really key ingredient here, because otherwise you are reinventing the wheel from scratch again and again, and before you know it, your P&L will eat you alive from the maintenance costs if your engineers don't all quit first. Okay, I feel like I just said a lot of words. Do people have a general idea of what I'm talking about? Yeah? Some hands. Okay, great, great. Oh my gosh, I'm above where I thought I'd be. So, okay, you're now saying, "Kevin, that's cool. You know, you've just told the story, you've given some frameworks, but then I'm not here to listen to you talk,right? I want to know how to apply this to my organization, to my business, how to bring this back to my team." So how do you go about doing that? First and foremost, and this is the thing that I advise to everyone who's thinking through the concept of Forward Deployed Engineering, is really ask yourselves, "Do I need an FDE function?" ### Starting FDE **Kevin Bai** [10:02] Like, do I need one? Not want,right? It's easy to want things that are in vogue. It's easy to want to do, you know, AI, because that's what everyone else is doing. But like, do I need one? Do I have some corner case in my business where I must, must GTM a technically complicated thing to a non-technical buyer? If I don't have a situation like this, probably FDE is not theright fit. There's a lot of great things you could do with DevRel and building a great developer engagement team if you're having a technical go-to-market motion. There's a lot of great things you can do with an SLG sales-led motion if you're doing more traditional SaaS,right? It's only in this situation where you need FDE. That's the first piece. So the second piece is, do I have a platform? Or phrased another way, am I willing to invest in building one? Because I assure you,right, no matter how tempting it is to have these engineers that can make you money, if they are not building on top of a platform with some number of shared primitives, you are in for a very bad time. I just, I could not begin to stress the amount of maintenance burden that will be on your team, even if you have a robust platform. Never mind if you don't have one. And so these are the questions that I would really encourage you to think about from an FDE 101 perspective of, do I have to sell something complicated to a non-technical buyer, and do I have a platform on top of which my FDEs can build? Okay, now for the AI piece, because that's obviously happening in 2026. What's changed since Palantir came onto the market, which I think was like 2004 or 2005 and now, is that artificial intelligence has made it really, really easy to build, really, really easy to write code, and also really easy to build sophisticated, customizable software for customers. ### Agentic Shift **Kevin Bai** [11:56] I mean, how many people in the audience are building agent for X, you know, insurance, legal, what have you,right? I don't even need to see the hands for this one. But the thing that's changed is not that the world has suddenly realized Palantir's FDE motion is a really good idea and they should do that. My personal hypothesis is that the thing which has changed is that the nature of doing business in the software industry itself is what's changed. Because now nearly every platform is agentic, and that means nearly every platform is customizable, and that also means nearly all of you are going to have a situation where your customers have no idea what the heck it is that you actually do, and if you leave the success or failure of your product to their hands and to their ability to implement, I assure you this is not, you know, like, going to be an easy motion as you try and sell either into the upmarket or try and expand horizontally or vertically. Allright, I think that's enough words out of me. I would really like to hear some questions from the audience. Anything and everything is on the table except my current work. Thank you. ### Q&A **Kevin Bai** [13:09] Hands? Yeah? **Guest** [13:10] You're talking about needing shared primitives. Can you give a little more detail, like, how atomic should these primitives be? Yeah, just some example of what I would look like. **Kevin Bai** [13:20] Yeah, that's a really good question. So. **Guest** [13:22] Can you repeat the question first? **Kevin Bai** [13:23] Oh, yes. So the question was, talk about shared primitives, how atomic should those shared primitives be? What does that mean? So, okay, if you are trying to sell a platform where you're building, you know, something that involves data models,right, perhaps one place to start is not having to, you know, define a data model from scratch. But I would say, you know, and this is a very lawyerly answer, is that it depends on what it is that you're getting into. There's a lot of industries and a lot of situations where you can get away with having very robust primitives,right, where the app itself is like 60% built and then people are just customizing the other 40%. And then there are certain use cases and certain industries and spaces where that's really not appropriate and you need extremely granular configurations and, like, extremely granular tooling. A good example of a platform that I think all of you should be familiar with is AWS,right? I'm sure, you know, many of the folks in the audience are really great engineers, and if you wanted to, you could, you know, buy your own server racks and then get them online and then maintain them. But who's really done that since, you know, the 1990s? But like, within AWS,right, they give you a shared set of primitives like DynamoDB, so you don't have to, you know, invent a database from scratch. But that's because they're trying to serve an extremely broad swath of customers. So it depends on your user base. Anyone else? Yes,right there. **Guest** [14:54] So have you seen cases where two FDEs with two different companies collaborate? And if so, how has that been? Is there friction? Is there what have you seen? **Kevin Bai** [15:06] Yeah. So the question is on what is the collaboration mechanism, you know, if two FDEs or multiple FDEs work on a project. I would say that's really encouraged. That's a really good pattern because especially when you're doing custom work for a customer, the last thing you want is like a single point of failure,right, where one person knows all the information, they go on vacation, and then you're kind of screwed. And so. **Guest** [15:29] Two different companies? **Kevin Bai** [15:30] Two different companies. **Guest** [15:31] Yeah, you go on, like, let's just say BWS sends an FDE to do a project. You go on in from Palantir? **Kevin Bai** [15:38] Like, working on the same project? Like a bake-off? Okay. Or like collaboration, like a partner. Yeah, yeah, that model exists as well. It's just no different than having a contractor,right? You have to figure out who the contractor is in that situation. But that's kind of the mental model. Allright,right there in the back. **Guest** [15:59] What is the decision-making that goes on when, like, how do you determine when to change, like, whatever change that needs to happen? Is it on the platform side or, like, the Forward Deployed Engineering? **Kevin Bai** [16:11] That is a really good question. The question is, what engineering changes go onto the platform versus what engineering changes go onto the Forward Deployed side? So anything that's bespoke and unique to a particular customer is something that should really only exist for that one customer. Anything that can be generalizable should be generalized in the long term. Now, when you begin your FDEing,right, probably you're not going to have a lot of different primitives, but that's okay because FDE is also a great way to scout ahead and to find what additional product services you can build upon to further enable the success of your business. How are we doing on time? Good? No, not good. Allright, allright. Last question. Right there. **Guest** [16:57] What is the perfect profile of an FDE? **Kevin Bai** [16:59] Oh, this is so good. What is the perfect profile of an FDE? So the tagline that I will leave you with is that a FDE is nothing more than a customer-facing software engineer. And so it is a person who you would hire as a software engineer on your team, but at the same time, you would trust them in front of a customer in some shape or capacity. And then the rest you'll have to figure out as you go because we are capped. Thank you so much. --- This library is powered by PodHood (https://podhood.com), the podcast website platform.