How many clients can one FDE carry? The answer depends on phase and tooling, not on a single number

How many clients does a forward deployed engineer usually run at once? No public source can answer this. The aggregator site theforwarddeployed.io admits that the public record has a gap here, and most first-hand accounts describe only “one deep embed at a time”.

The original models all point towards one. PostHog describes its FDEs doing product discovery and development with one client at a time. According to Rocketlane, Palantir’s FDSEs embed deeply with exactly one customer at a time. Yet Atlassian says its FDEs have worked with more than 100 enterprise customers.

This paradox matters to you because it shapes how your work gets assigned. Carry eight accounts at once with all eight in deep build, and you will burn out.

If you understand what pushes the ceiling up and what drags it down, you can negotiate scope, design tooling and give better answers when a recruiter asks.

Counting clients is the wrong question

A more useful question is what phase each account is in. An analysis on zarifautomates.com of when to hire FDEs says plainly that the deep build phase can take up most of one engineer’s time, while a stable account needs far less.

Its advice is to plan capacity by phase rather than by a fixed number of accounts, and to keep time in reserve for productisation and documentation.

Try a hypothetical portfolio. You have one client in deep build, roughly 60% of your week. One client in rollout takes about 20%. Four stable clients take 5% each. That adds up to six accounts and exactly 100% of your time, with nothing left for productisation.

Now sales closes a new client, and it goes straight into deep build. On paper the portfolio grows only from six to seven. In practice your load jumps to about 160%. Counting accounts hides this jump. Looking at phases makes it obvious.

The portfolio decides whether it is three clients or eight

The range of 3–8 projects is an argument drawn from the phase logic above, not a figure any company has published.

The low end fits a portfolio with one or two clients in deep build, where every new client has to take time from an existing one. The high end only works when most accounts are stable and tooling handles the repeated work.

Load is also not carried by individuals alone. According to theforwarddeployed.io, Palantir’s customer teams are usually only 4–5 people, working quickly and autonomously. When you read “one FDE, one client”, the real picture is often a small team sharing one large account.

Putting the models in one table shows that each holds the ceiling in place with a different mechanism:

Model	Clients at a time	What holds or raises the ceiling
PostHog	One client at a time	A small team has to choose carefully where to spend time; repeated patterns become internal tools
Palantir	One client per FDSE	A 4–5 person customer team shares the load
Atlassian	More than 100 enterprise customers in total	The platform turns one team’s solution into a capability every customer can use
Perspective AI playbook	Rotating portfolio	Handover within 120 days of go-live; target of 70%+ of code in the main repo

The table shows that one client and a hundred are not in conflict. They are two points on the same curve, and the curve gets steeper as client work is turned into product.

How does tooling raise the ceiling?

The article on zarifautomates.com puts the rule most simply: work repeated across accounts is a product requirement, not a services problem. That is the mechanism that raises the ceiling. Each time a piece of work moves off your task list and into the product, the deep build phase at the next client gets shorter.

PostHog’s handbook makes this part of the job: build reference implementations, sample examples and internal tools so that later engagements move faster. Atlassian goes further and designs its whole platform so that one team’s solution becomes a capability every customer can use.

The Perspective AI playbook proposes a specific measure, the reusable-asset ratio: how much code goes into the product repo compared with code that sits in each client’s own repo. The target is more than 70% in the main repo by month 12.

Go back to the example. If most of what you wrote for the sixth client is already in the main repo, the seventh might take only 30% of your week instead of 60%.

Knowing when to leave matters as much as taking on new clients

Tooling shortens the deep build phase. Without an exit, though, your portfolio keeps growing because old accounts are never handed back. Perspective AI suggests most engagements should be handed over to customer success and product engineering within 120 days of go-live. The portfolio then rotates instead of piling up.

Rocketlane also stresses that healthy organisations agree scope, milestones and exit criteria before every FDE assignment. Note that Rocketlane sells PSA software.

Its claim that FDEs spend 40–60% of their time on administrative work should be treated as an unverified marketing claim. Even without that number, the principle of agreeing the exit in advance holds.

In the hypothetical example, the four stable accounts take 20% of your week. If two of them are handed over on time, you get back about 10%. That time should go into moving code into the main repo. It is an investment in the next client, not spare capacity for more work.

Employers want to see that you can raise the ceiling

When interviewing for an FDE role, do not just ask “how many clients does each person handle”. Ask how the company plans capacity, when an engagement counts as finished and who takes over at handover. A job description that mentions exit criteria, reusable tooling or contributions to the product repo is a sign the organisation has thought about scale.

On a CV, “managed 8 enterprise clients” says very little. A stronger line describes the mechanism: you spotted work repeated across several clients, turned it into a tool or module in the product, and that cut the next engagement by a stated amount of time.

Use your own real numbers. Employers want to see that you know how to raise the ceiling, not just that you can put up with a heavy load.

If you already work as an FDE, keep a load table by phase and update it every week. It lets you turn down the seventh client with data rather than gut feeling. It also shows the product team exactly where to invest.

A good FDE does not measure themselves by how many clients they are carrying. A better measure is how much less of their time the next client will need.