Forward-deployed engineers (FDEs) are having a moment. Whether called “agent engineering” at Sierra, “customer engineering” at Shield, solution and sales engineering elsewhere, or their original name, “Delta”, they sit at the intersection of sales, engineering, and customer success, translating real-world complexity into product insight.
As AI products collide with messy enterprise reality – legacy systems, ambiguous workflows, and proprietary data – companies are rediscovering a Palantir-era tactic: embed engineers directly with customers to make the product actually work.
The appeal is obvious. FDEs compress sales cycles and bridge the gap between elegant demos and operational reality (hence their original name “Delta”), but they are a double-edged sword. At best, they create a tight feedback loop between the customer and product, but if done wrong, they can quietly transform software companies into bespoke service firms with bloated CAC, fragile margins, and roadmaps dictated by their loudest customers.
The question is not whether to build an FDE team, but how to design one without undermining the very economics that make software valuable.
FDEs are most effective when the product is powerful but the “last mile” is highly contextual. This describes the industry standard in AI and data infrastructure, where value depends on wiring into proprietary workflows and compliance constraints that no roadmap can fully anticipate.
They are also vital in design-partner markets. When early customers effectively co-create the product, FDEs become the fastest feedback loop between reality and code. In competitive markets, the second-best product with strong FDE support often outperforms the technically superior product that customers cannot operationalize.
- The Danger Zone: FDEs become toxic when custom work becomes the default. If every deal requires bespoke engineering, you don’t have a product; you have a consultancy with a logo. When “we’ll just throw an FDE at it” becomes an organizational reflex, product debt accumulates silently. Customers outsource their thinking to your engineers, and you inherit their complexity.
- Rule of Thumb: If more than 30-40% of deployments require significant FDE effort, the problem is no longer go-to-market. It’s product design.
The central tension here is economic. FDEs create real cost, but professional services revenue hurts valuation multiples.
- The Services Model: Billing time-and-materials keeps margins clean but dilutes valuation. What’s worse is that customers anchor on hourly rates rather than product value.
- The Bundled Model: Bundle FDE costs into the subscription price. It preserves “software-only” optics and simplifies procurement. It’s the pragmatic choice in early stages. However, it inflates subscription pricing and obscures the true drivers of CAC and gross margin.
The Solution: A milestone-based embedded model. FDE support is included in the deal but tied to defined milestones (e.g., “successful deployment”) rather than open-ended engagement. Embedding must be time-bound — usually three to six months. If customers cannot graduate from FDEs, the product is not ready.
For companies offering FDEs, financial planning and analysis are usually more troublesome than the actual engineering.
The uncomfortable truth is that FDEs often make metrics look better externally, but worse internally.
- Revenue: Only software counts as ARR. FDE revenue should be internally unbundled, even if external reporting lumps it together.
- CAC vs. COGS: Pre-sales FDE work is CAC. If you don’t track this, you will drastically overestimate your GTM efficiency. Post-sales work is Services COGS.
Finance teams must enforce an honest distinction between software margins and deployment margins. If FDEs are essential to closing every deal, your product is not yet self-serve at the enterprise level, and your P&L should reflect that.
The legal stance must be absolute: The company retains full IP ownership of all FDE work. Customers get a royalty-free license, but reusable components must flow back into the core product, not remain trapped in customer-specific forks.
Where FDEs actually sit is equally consequential:
- Reporting to Engineering: Better code quality, weaker revenue alignment.
- Reporting to Sales: Higher responsiveness, but a high risk of “short-term hacks” that create technical debt.
Best Practice: A dual-reporting model where FDEs sit within a Customer Engineering org but maintain a dotted line to Product. Crucially, rotate FDEs between customer sites and core development. This prevents “maintenance mode” burnout and ensures the FDE team doesn’t drift into a consulting mindset.
Forward-deployed engineers embody your product strategy, and your comp plan will dictate their behavior.
- The Sales Model: Paying FDEs commissions on closed deals encourages them to optimize for immediacy. Custom solutions multiply, and the company scales exceptions rather than a platform.
- The Core Model: Paying high base salaries with no variable component produces clean code but low urgency. Architectural purity takes precedence over customer timelines.
The companies that win must reject both extremes. They pay FDEs at engineering levels (read: equity-heavy) but introduce a restrained variable component tied to outcomes that signal maturity: successful deployment, retention, and the conversion of custom work into core product capabilities.
- The Activator (e.g., Sierra): In AI platforms, FDEs act as “agent product managers,” translating enterprise complexity into deployable systems. This is powerful but fragile, and must therefore be temporary.
- The Integrator (e.g., Ramp): In fintech, FDEs bridge the gap between modern software and legacy ERPs, banks, and internal tech stacks. They are the difference between a mid-market deal and a multi-million-dollar enterprise contract, provided they don’t let big customers hijack the roadmap.
- The Infrastructure (e.g., Palantir): When every customer requires embedded engineers forever, product velocity dies. Palantir built a giant business this way, but they operate in a market with extreme switching costs and existential stakes. Most startups do not have that luxury.
Many startups today use FDEs to compensate for immature products, unclear positioning, weak onboarding, missing integrations, and unrealistic enterprise promises.
In the ideal model, FDEs feed R&D. Each deployment generates insight into data schemas, workflows, edge cases, and constraints. Those insights become reusable features. If three FDEs solve the same problem, the solution becomes a native capability.
The real question is not whether to build an FDE team. It is how long you plan to depend on one.
FDEs are a mirror. They reveal the gap between what your product promises and what customers actually need. The companies that win treat FDEs as scaffolding – never as architecture.
