FDE Economics: Commercials and scaling of the FDE model

Scaling the forward deployed engineering (FDE) model means growing an FDE team without letting delivery cost outrun the value it creates. In this community panel hosted by Rocketlane’s CEO Srikrishnan Ganesan, Paul Staelin, Chief Customer Officer at Relevance AI and Varun Jadia, Senior FDE at Rippling shared how they scope engagements, price them, structure the team, and exit accounts without losing the relationship in the process.

The clearest lessons to come out of it are these: both teams have moved away from optimizing for headcount growth and toward optimizing for reusability. Neither approves FDE work anymore unless the output can be pulled back into the product and sold broadly, not just delivered once and forgotten.

This recap walks through seven decisions every team scaling an FDE function eventually has to make, from pricing models to the exit paradox, with the specific approach each panelist actually uses. 

What does a scalable FDE engagement actually look like?

Picture this: Somewhere, right now, there’s an FDE who’s talking to a customer they first spoke to fourteen months ago. Nobody decided this would happen. And that’s the problem. Nobody decided anything. There was never a moment where the team decided “we’re done”. That’s scary. And worse, costly and not scaleable.

Here’s what our panelists said when asked how they make FDE engagements scalable. Relevance AI used to run FDEs the old way, meaning they assigned someone to an account, let the relationship define the work, and hoped it winds down naturally at some point. No surprises here: It didn't. So what did they do? They moved to scoped, PS-style engagements instead. This means that contracts now carry an hours cap, something like 200 hours, tied to two defined agentic use cases as the actual deliverables.

What’s important here is that the cap isn't there to police the timesheets. It's there so someone on the team can have an uncomfortable conversation with a customer before the scope goes out of hand.

For Relevance AI, the whole point of all this is to work yourself out of the job. That happens when you train the customer's builders well enough that the FDE drops from a daily presence to an hour a week of advisory check-ins, and eventually, out of the project entirely.

Rippling pushes the same idea, but much earlier in the engagement: before an FDE is even in the room. Every engagement runs off an SOW (Statement of Work) with the exit criteria decided from day one, and deals have to clear a pre-sales qualification gate first: can we actually build this, and do the APIs exist to support it?

Honestly, a lot of deals die right there, and that's the point. 

If a deal that shouldn't have qualified gets through, it is a lot more expensive to unwind six weeks into delivery than it would have been to reject it up front. The deals that survive this step goes to a single FDE who owns it end to end, from scoping through to build, so that there's no handoff tax or any lost context halfway through the engagement.

What we see here is that while both companies are setting up the constraints at different points in time, the core idea is still the same: the constraint comes before the work, not after.

Here’s a quick takeaway for you from the panel: if you audited your current FDE engagements right now, how many of them have an actual exit date, and how many are operating on a vague sense that things are "going well"? The gap between those two answers is usually where your margins are leaking.

How should you price a forward deployed engineer?

This is a question that’s on almost everyone’s mind. But here's something nobody wants to hear: there isn't one right answer yet. If you're looking for the industry-standard FDE rate card, you can stop looking right now. It doesn't exist. 

But the closest you can get to that is from what our panel had to say.

Firstly, Relevance AI technically has a fee. So yes, on paper, there's a number attached to FDE work. However, in practice, that number gets discounted around 95% of the time. What does this tell you? The fee isn't really a revenue line. It's more of a parameter-setting tool.

The whole reason they do this is that putting a price on the table, even though it is anyway about to get knocked down, forces a scoping conversation that you’d not get from a free engagement. 

In contrast, Rippling went the other direction entirely. FDE work gets priced as a net-new ARR (Annual Recurring Revenue) SKU, stacked on top of the core subscription. That’s a real revenue line with a real number on the contract.

Maintenance isn't billed separately; it's folded into that ARR, on the logic that recurring revenue already covers ongoing support. The net effect? What you bill for the FDE work isn’t just a signal for seriousness the way Relevance AI’s is. It’s its own product line with its own case for renewal.

Okay, this is all operational. We know how they bill the work, but how do you actually arrive at the number to quote?

Pull the pricing philosophy apart from the pricing number, and both teams are running the same math underneath. Start with the admin time the customer saves, then convert that into a dollar figure. That's the base number.

Then you start making the judgment calls. How much effort does the engagement actually take? How much value does the customer perceive, which isn't always the same as the real value? And you also add a few factors that never show up on a spreadsheet: what segment the customer's in, and how badly you need to keep this particular logo happy.

In other words, this is value-based pricing with a heavy dose of judgment layered on top.

Where should the FDE team sit, and what should it be measured on?

This is probably one of the most important questions you’ll have to answer when setting up your FDE team. And this is also one where you could get as many answers as the number of people you ask. Ask five FDE leaders where their team reports, and you'll get five different org charts. But the key is to then ask them why, because only the good ones will actually have an answer. The rest will just say "that's just how it ended up."

This panel's answer was cleaner than most: the reporting line should follow the metric, and shouldn’t be based on convenience. 

At Relevance AI, FDE reports to the CCO, who reports to the CEO, and the number that matters is net revenue retention. The reporting line simply follows the metric: NRR is a commercial number, so FDE lives in the commercial org.

It's really not that complicated, but it’s important to note that this isn’t accidental. It was deliberately planned to be this way. If you're going to hold a team accountable for expansion revenue, having them report to engineering wouldn’t make the most sense, would it?

Rippling drew a different line, and for a different reason. Here, FDE sits inside Customer Experience, and the north star is churn prevention, not revenue growth. Don’t get us wrong, they still track ARR generated, that number matters too. But if you had to pick the one metric that decides whether the team had a good year, it's whether the accounts stayed. 

This raises a question worth asking about your own team. If someone handed you your FDE org's headcount growth chart with the metric labels taken off, could you guess what they're actually optimizing for? If the answer is no, the reporting line probably isn't doing its job.

However, both teams also flagged one issue that they are yet to solve.

When an FDE ships something that gets reused across ten other accounts instead of staying unique to one, who gets credit for that?

This is a complicated question. Sales didn't close it as a deal. It wasn’t built as part of the product roadmap either. And while it did come out of a customer engagement, it's now a permanent part of the product. So what do you do? Neither panelist has a clean attribution model for this yet, and if you're running an FDE org and you do have one figured out, let us know. You're ahead of two companies that are otherwise pretty far along.

What both teams have agreed on, even though they haven’t agreed on the metric, is what they're NOT optimizing for anymore.

Headcount used to be the vanity number: bigger team, bigger budget, bigger seat at the table. Now it's a side effect. The real shift, in the words that came up more than once on the panel, is reusability over headcount growth. Your team gets bigger because the work demands it, not because bigger looks better in a board deck.

So before you write down a headcount target for next year, ask what number is actually driving it. If you can't name the metric, you're probably still optimizing for the org chart instead of the outcome.

Why the product feedback loop decides whether the FDE model scales

Here’s a fun experiment for you to run. Ask a few FDE teams how many of their last quarters builds made it back to the actual product. If the answer is none of them, is that really an FDE team? Or is it a bunch of consulting projects masquerading as one?

Both panelists agree that the loop back to the product isn't a nice-to-have. It’s something more than something you can present as proof of "cross-functional alignment." It's the actual economic engine. Without it, an FDE function is just a build shop wearing a platform company's badge. And these don't scale, they just hire more people.

Relevance AI backs this up with a standing weekly meeting, an "interlock" across pre-sales, implementation, support, and engineering. Its only job is turning field patterns into roadmap decisions in real time. If three customers hit the same wall in the same month, it's treated as a signal for the roadmap to look into.

The second piece is what happens once that signal lands. Coding agents have changed what an FDE can actually ship, so instead of just flagging the problem and waiting on engineering's backlog, FDEs at Relevance AI push the fix themselves, as a PR straight into the codebase for approval. The FDE isn't reporting a problem anymore. They're shipping the fix.

Rippling built the same instinct into the org chart itself. FDEs sit next to platform engineering from day one, right from the start. That placement alone changes what the role does day to day: weekly syncs keep the bug-to-fix cycle fast, and FDEs end up acting as product engineers on short timelines instead of consultants sitting in a ticket queue waiting for someone to prioritize their problem.

The payoff shows up earliest, before a feature even ships. When product teams need someone to stress-test something like an MCP gateway before launch, they don't need to pull from a beta customer list. Instead, they can just pull in an FDE, because an FDE already knows where the real edge cases live, the weird account configs and edge-case workflows a beta customer would never think to try.

Here's the part worth actually stealing, though, more than the org chart or the meeting cadence: the gate. Neither team lets an FDE take on work just because a customer asked nicely and the timeline is scary. The work only gets approved if the output can be pulled back into the platform and sold broadly. That's the whole test. Not "does this help the account?" Why? Because almost anything helps the account. The question is whether it helps the next twenty accounts too.

Ask yourself honestly: does your FDE team have a version of that gate, or does "the customer needs it" count as approval enough on its own?

The new economics: managing AI and token cost

Let’s face it: Running an FDE team is already expensive. Salaries, travel, and what not. But there’s a new seat at the table, and this one tends to fly under the radar. Because it doesn’t take PTOs or ask for a raise, and yet, can blow through your budget if you’re not careful. Its called “the model”, and if you aren’t managing token usage, you could be in for a nasty surprise.

Relevance AI's answer to this problem is almost boring, in a good way: Just shop around for the right model for the right job. That’s it. Not every task needs the most expensive model on the market, and treating that choice as a real decision to make instead of just resorting to the default is exactly why the team's own token costs end up, in the panelist's words, shockingly low. It's a habit, not a one-time fix, and habits are what actually hold up at scale.

The more interesting twist shows up on the customer side. As customers actually use what the FDE builds, their own token consumption climbs too. Relevance AI treats it as revenue upside. Usage going up is the metric you want to see, not the one that keeps someone up at night.

Rippling learned the same lesson the harder way. Back in February and March, token spend across engineering ran away from them, and ended up at the kind of number that gets a budget line frozen and a policy written in the same week.

So that's exactly what happened: hard token budgets were enforced across all of engineering, with no exceptions carved out for FDE work just because it's customer-facing. Team token spend is now tracked as closely as any other scaling metric, right alongside headcount and utilization.

And on the customer side, the same math shows up as it did at Relevance AI: consumption on Rippling AI is revenue-positive. That's part of why they're building custom agents and skills on top of it now, instead of treating token usage as pure overhead to control.

Here's why this section matters more than it might look like it does: almost nobody writing about the FDE model right now is talking about token economics. It's a blind spot in most of the public thinking on this role, which makes it worth asking early, before your own spend runs away from you the way Rippling's did. Do you know what your FDE team's token cost per engagement actually is? And we don’t mean roughly. We mean precisely.

If the honest answer is "we haven't looked," then well, the good news is if you look at it now, you get to fix it before the budget conversation happens for you.

Who makes a great forward deployed engineer?

Here’s another fun exercise to run: Post a job listing for "forward deployed engineer" and watch what happens. You'll get a lot of software engineers who will struggle with running discovery calls, and a lot of consultants who'd freeze the second they have to debug something. Neither one is the right hire.

So, how do you end up hiring the right person?

Relevance AI hires for a solutions-engineer skill set, typically five to seven years of experience, people who can bridge business and technical conversations without needing an interpreter in the room.

But the more telling detail is who they pair that hire with: a "deployment strategist," someone with a PM/MBA background whose entire job is checking that the problem being solved is one the business actually cares about.

That's not a redundant hire. It protects them against the very thing that kills FDE engagements: building something technically impressive that nobody even needed.

Rippling's framing, borrowed from the panelist's own words, is blunter: consultant plus PM plus engineer. In practice, that skews toward the PM and engineering side.

But the job still demands things a pure engineer usually isn't trained for: running the demo, writing the deck, sitting through a tough customer call where the account is unhappy and somebody needs to actually listen instead of defending the roadmap.

The qualities that matter most in those moments aren't technical at all. Deep listening. A real grip on what the customer's actual problem is versus what they say it is. Enough scrappiness to ship a hacky workaround today instead of waiting for the clean solution next quarter.

So, here’s what you learn from this and apply to your own team. If you handed your best FDE a messy, half-explained customer problem with no clear technical path, would they ask better questions or write better code first? Both matter. But which one they reach for first tells you which half of the role they're actually built for.

The profile isn't fixed, either. It shifts with what you're building. Agentic, composable products push the mix more technical, because the FDE is often the one wiring the thing together in real time. Simpler platforms can lean harder on business logic and prompting than on raw engineering skills.

There's no universal job description here, just a spectrum, and where your product sits on it should decide who you're hiring, not a generic template pulled from someone else's org.

What both panelists agreed on, underneath the different framings, is that the failure mode is never really technical. Nobody's FDE engagement has collapsed because the code didn't work. It collapses because the FDE built the wrong thing, confidently, for months, because no one on the team was actually checking whether the business cared.

The hardest problem: how do you exit an account?

There's a cruel little paradox sitting at the center of the FDE model, and both panelists said the same version of it out loud: the better the FDE, the harder they are to pull off the account. Do your job well enough, and the customer never wants you to leave. Success, in this role, can easily end up becoming the trap that keeps you stuck.

Relevance AI's answer to this leans on enablement. Train the customer's internal builders well enough, early enough, that the FDE's presence can shrink on its own terms instead of getting yanked out. Done right, that FDE steps back to something like an hour a week of advisory time, still present, but no longer holding the account together. It only works, though, if the customer has people capable of being trained in the first place.

Rippling doesn't always get that luxury. A lot of their ICP (Ideal Customer Profile) is non-technical, HR and payroll admins who were never going to become the internal builder in this story. So the fix has to happen earlier, and look different.

What this means is that exit criteria go into the SOW before the engagement even starts, not as an afterthought once the account gets comfortable. AI-powered self-serve, skills and plugins, gets built so customers can answer their own questions before ever needing to reach an FDE. And reusable solutions get prioritized over unique ones for a specific reason: The unique work is what makes an account impossible to exit. If nobody else understands the thing you built, you're the only one who can maintain it, forever.

One detail from the audience floor was sharp enough that it deserves its own space here. Someone from Sonos described a premium support role: a bridge function, a recurring fee, built specifically to pull top FDEs off accounts without leaving the customer stranded. The FDE's documentation feeds into an MCP that handles first-line support instead. It's not a clean handoff to nothing. It's a paid, structured landing pad, and it's the kind of idea that probably belongs in more FDE playbooks than it currently does.

Ask yourself where your best FDE is right now, on your best-performing account. If the honest answer is "still there, eighteen months in, because nobody's found a way to leave,” what you have is a bottleneck wearing a success story's clothes.

How Rocketlane sees the FDE model

Everything on this panel, the scoping discipline, the pricing debate, the exit paradox, plays out inside Rocketlane's own walls too. We run a forward-deployed motion ourselves, which is part of why this panel's themes tracked so closely with our own FDE Blueprint.

The platform side of that is Rocketlane's Nitro, the agentic AI layer inside our PSA that FDE teams use to scope, price, deliver, and exit these engagements without rebuilding the wheel in a spreadsheet every time. Nitro's Workforce and Migration agents take on the repeatable build and migration work, the stuff that doesn't need a judgment call, so FDEs stay focused on the problems that actually do.

It's the same instinct behind the product feedback loop from earlier: automate what's reusable, save the human for what isn't. The key thing here is that the platforms move from merely tracking work to actively executing it, and that’s a bet on where FDE work is headed.

Quick Summary

• Scope with a finish line. Scalable FDE engagements have a defined end, an hours cap, or a SOW with exit criteria and a pre-sales qualification gate, never an open-ended assignment.
• Pricing is still unsettled. The spectrum runs from a mostly-discounted fee to a net-new ARR SKU, but both approaches reason from the same value logic: admin time saved, converted to dollars.
• The reporting line follows the metric. Teams measured on net revenue retention sit in the commercial org; teams measured on churn prevention sit in customer experience.
• Reusability beats headcount. Both teams have shifted focus away from growing the team and toward growing what gets reused, though R&D attribution for that reused work is still unsolved.
• The product feedback loop is the economic engine. FDEs push code back to engineering, and work only gets approved if it can become platform capability that's sellable beyond one account.
• Token cost is now a scaling metric. Managed through model shopping and hard budgets on the team side, with rising customer consumption showing up as a revenue stream on the other.
• The exit paradox is the hardest part. The better the FDE, the harder they are to pull off the account, solved through internal-builder enablement, AI self-serve, reusable-over-bespoke builds, or a premium-support bridge role.