This is an opinionated guide on how, as an organization, to structure your FDE motion. The goal is to share a financial framework for decideing where and how you deploy the team.

This assumes that you have identified a need for FDE: there’s a last-mile gap between what the product does out of the box and what a customer needs to activate. These are high-value customers and you’ve decided it’s worth putting a little extra “oomph” behind getting them on board.

FDEs, by definition, are engineers. They are building new features, fixing bugs, writing one-off scripts to pull data, and bulk loading customer configurations into the system. As with all engineering, FDE output should be multiplicative.

How to measure ROI

It's helpful to have a sense of the ROI for FDE projects. (Certainly your finance team will want justification when FDE inevitably wants more headcount.)

1. Revenue attribution. FDEs should track revenue associated with things they've built. That is, “without FDE’s involvement, we would not have landed the deal.” This can be further broken down to pre-sales (new account activation) and post-sales (expansion opportunities.)

2. Multiplicative efforts. A common failure mode is to forever build one-off features. FDEs should either build things that can be fully launched in the product, or have a commitment from the rest of eng to “productionize” the work.

   Measure how many customers - or revenue - is tied to FDE-built functionality. In the best case, your deal pipeline is accelerating due to better PMF with enterprise customers (who you observe are using FDE features.)

   What about truly one-off customer-specific requests? Make your software extensible - i.e. publish APIs - and have a consulting motion for customization.

3. Reduce onboarding costs. FDEs should be building tools and automation that make it easier to onboard and support customers.

   Every manual SQL query should turn into a user-downloadable report or a CSV import. Invest in working demo environments with have realistic data. Customers and CSMs should have dashboards for onboarding.

   You can observe this in a decrease in the number of support tickets that FDEs are handing, along with speedier activation times.

As a bonus: in the year 2026 you should be enabling your CSMs to vibe code their own tools. What are the safe, observable, roll-back-able APIs you can build to enable this?

To charge or not to charge?

I am generally in favor of charging customers for FDE work.

1. Customers have skin in the game and tend to move quicker to make good on their investment.

2. It is a fantastic lever to reduce scope creep and agree upon a definition of “done.” Fees help separate nice-to-have features from actual blockers.

3. Pricing conversations give information about PMF (”your competitor already offers this for free out of the box”)

4. The dollar (and the hour) is the lingua franca across all business units on both your and the customer’s side. For example, it helps a decision-maker unblock when someone in the chain is delaying a project - and running up a tab.

   Internally, it sets the stage for conversations around whether it is worthwhile to take on a task in terms (dollars + hours of finite capacity) in a way that sales leaders can understand.

   Engineers are averse to hourly tracking so I don’t recommend doing it. However, FDE leaders should translate story points, t-shirt sizes, and sprints into hours in order to speak the same language as the rest of the organization.

My basic pricing framework is:

1. FDE may or may not choose to take on a project - they’re in the driver's seat for prioritization.
2. Any FDE work should be billed by default. Engineers are responsible for estimations of effort.
3. FDE fees can be waived, with leadership sign-off, if the customer will be at least break-even for the first year of profit.
4. You may be lenient on pricing if the feature would be useful for many businesses. Hold the GTM team accountable to winning that business.
5. Fees can be waived If there is a strategic logo that executive leadership feels is worth pursuing.

With these critiera, your AMs will magically find that every deal is “strategic logo” and every feature something "that will be useful for many businesses."

That’s why it is leadership, not ICs, who determine which of these buckets FDE work falls into. FDE capacity is a finite resource so you want to be thoughtful about where to deploy.

Summary

FDE exists to support business goals, and at different stages, a different set of rules for how to deploy FDEs will make senes. In the early stages you probably need to white-glove every customer. As your revenue targets grow, you'll want to restrict your FDE deployment to your larger customers. The mixture of paid vs non-paid work will change as the business changes.

I encourage you to be quantitative about it: there is an opportunity cost when you put FDEs on a project. Take the time to measure success criteria, and it will help justify headcount and make sure the team isn't toiling on low-value work.