How Many FDEs per Customer?

Every founder who hires FDEs eventually asks the same question. How many do I put on each customer? You will find confident answers online. Most of them are made up.

Here is the honest version. No company we know of has published a universal FDE-to-customer ratio. What has been published is more useful anyway: how the teams that built this function actually structure their pods, and what they watch to decide when to add or pull people. This guide covers those models, then gives you a framework and a few worked examples you can adapt.

What the Teams That Scaled It Have Published

Palantir: Small Customer Teams, Paired Roles

Palantir invented the modern FDE role. Its own blog post Dev versus Delta draws the core line. Product engineers (“Devs”) own one capability across many customers. Forward deployed engineers (“Deltas”) own one customer across many capabilities. The post says Delta teams directly support a single customer.

Palantir also pairs Deltas with a second role. Its Deployment Strategist job posting splits the work clearly. The strategist learns the users, the problem, and the data. The forward deployed engineer builds the stable, extensible pipeline that brings the data in. Internally the strategist is often called an “Echo,” a term a16z’s Marc Andrusko mentions in The Palantirization of Everything. The pattern is simple: one person owns the why and the what, one owns the how.

How big do these teams get? Nabeel Qureshi, who worked as an FDE there, writes in Reflections on Palantir that customer teams were often four to five people, moved fast, and ran autonomously. That is one person’s account of one era, not a policy. It is still the clearest public number from inside the company.

OpenAI: Phases, Not Fixed Headcount

The Pragmatic Engineer’s deep dive on forward deployed engineers describes how OpenAI’s FDE team runs a customer engagement in three phases. First comes early scoping, with a couple of days on site. Then validation, where the team builds evals and checks results against goals. Then delivery, with FDEs on site a few days a week building the smallest end-to-end solution.

The lesson for staffing: intensity changes by phase. The team that scopes is not necessarily the team that sustains.

Ramp: Pods Inside Product

The same Pragmatic Engineer piece reports that Ramp’s FDE team, roughly fifteen engineers at the time, is organized in pods, and that Ramp’s job ads describe FDEs embedding within core product engineering teams. The details of Ramp’s operating principles are behind the paywall, so we will not guess at them. The structural point is public: pods that sit close to product, not a separate services department.

Where the Investors Land

a16z has written twice on this. Joe Schmidt’s Trading Margin for Moat argues that forward deployed work lowers gross margins at first but can build a moat, and urges teams to start small in scope and pick customers that share systems and use cases. Andrusko’s later piece is more skeptical. He suggests founders set guardrails such as a cap on engineering headcount relative to each account’s revenue, and argues FDE effort on a mature customer should fall over time. If it does not, ask why.

Marty Cagan at SVPG adds the product view in Forward Deployed Engineers. The model works when learnings from many customers get turned into reusable platform pieces. Without that, you accumulate bespoke systems you must maintain forever. That maintenance load is a staffing cost, and it compounds.

The Takeaway From the Published Models

Put those sources side by side and three patterns hold:

1. Pair skills, not just headcount. Palantir pairs a builder with a problem-owner. Many AI companies split the same work between an FDE and an account or deployment lead.
2. Staff by phase. Heavy at the start, lighter once the system runs. OpenAI’s phases and Andrusko’s test that effort should fall over time both point here.
3. Keep FDEs close to product. Ramp embeds pods with product teams. Cagan and Andrusko both warn that isolated FDE teams drift into a services business.

A Framework for Your Own Ratio

Instead of a magic number, score each customer on four factors. Each pushes your staffing up or down.

Deployment Complexity

This is the biggest driver. Ask:

• How many systems do you have to integrate with?
• Is the environment on-prem, air-gapped, or behind strict security review?
• How messy is the data, and who controls access to it?

One clean API integration is a part-time job. Five legacy systems inside a regulated bank is not.

Contract Size and Strategic Weight

A large contract can justify more people. So can a small one that is your first customer in a new vertical, because what you learn there becomes product. Andrusko’s headcount-per-revenue guardrail is a useful check here. Pick your own number, write it down, and notice when an account blows past it.

Phase of Deployment

Most deployments move through something like:

• Scoping and pilot. Heavy discovery. Short, intense, often on site.
• Build and rollout. The most engineering hours. Integrations, edge cases, user training.
• Steady state. Monitoring, small changes, expansion conversations.

Plan to taper. A customer that still needs full pilot staffing six months later is telling you something about your product or your scope.

Product Maturity

The less your platform does out of the box, the more your FDEs build by hand. Early on, almost every deployment is custom. As the platform matures, the same work becomes configuration. Cagan’s point is that this shift is the whole goal. Track how much each deployment reuses from the last one.

Illustrative Scenarios

These are examples to show how the factors combine. They are not data from real companies.

Example A: Early-Stage AI Agent Startup, First Enterprise Customer

You have five customers and a young product. Your newest customer is a large insurer with three internal systems and a security review.

• Complexity: high. Contract: large. Phase: pilot. Product maturity: low.
• A reasonable setup: two FDEs full time on this account, plus a founder or account lead owning the relationship. That mirrors the builder-plus-problem-owner pairing.
• Plan to drop to one FDE after rollout, and write down what would need to be true for that.

Example B: Growth-Stage Company, Mid-Market Customers on a Mature Platform

Your platform handles most integrations through configuration. Customers are similar to each other.

• Complexity: low to medium. Contract: modest. Phase: mostly steady state. Product maturity: high.
• A reasonable setup: one FDE covers several accounts at once, with a pod of three or four FDEs sharing a book of business and one lead triaging escalations.
• New deployments get a short burst of focused time, then join the shared pool.

Example C: Regulated or Government Customer

The customer is on-prem, needs cleared staff, and requires people on site.

• Complexity: very high. Contract: large. Phase: long build. Product maturity: varies.
• A reasonable setup: a dedicated team of several people, close to Qureshi’s described four to five, with one engineer focused on infrastructure and access, others on the application layer, and a deployment lead.
• Expect slower tapering. Build that into your margin planning from day one, as Schmidt advises.

Signals You Have the Ratio Wrong

Too few FDEs:

• Deployments slip because one person is waiting on access at three accounts at once.
• Your FDEs stop writing code and spend all day in meetings.
• Customers escalate to your CEO.

Too many FDEs:

• FDEs are building things the customer never asked for.
• The account has been in steady state for months, but staffing has not changed.
• Product is not hearing from the field because everyone is heads-down on custom work.

Review each account’s staffing monthly. Write down why each FDE is there and what would let them roll off.

Pod Structure That Scales

Once you pass a handful of FDEs, move from one-person-per-account to pods. A common shape, based on the published models above:

• A pod lead who owns customer relationships and prioritization, often a senior FDE or a Head of FDE.
• Two to four FDEs who share a set of accounts so knowledge is not trapped in one head.
• A standing line to product, through regular readouts or an embedded product engineer, so repeated custom work becomes platform work.

The Pragmatic Engineer reports that OpenAI’s team runs knowledge-sharing sessions, product readouts, and a field-notes channel. Small rituals like these are what turn five deployments into one product.

If you are bringing on new people to fill these pods, read our guide on your new FDE’s first 90 days before you assign them a customer.

Where We Come In

Forward Deployed Hiring vets every candidate on a technical screen and a live customer role-play before you meet them, so the people you add to a pod are ready for customers. You run the final interviews. It is free to interview our candidates. Start hiring when you know your next pod needs a person.