What is FDE (Forward-deployed engineering)? Definition, origins, and when to use it

One-sentence definition: what is FDE (forward-deployed engineering)?

Forward-deployed engineering is a software delivery model where engineers work directly at the customer's site instead of remote offices, collaborate alongside business, IT, and frontline teams, and carry systems from functioning prototype through daily production use.

The key is not writing additional code. It's embedding technology into a specific company's actual processes, data, and operations. A forward-deployed engineer owns this work.

Consider a recent case at Tenten. A customer had deployed a well-reviewed AI customer service system six months earlier. The contract signed quickly, and everyone nodded at the demo. When we assessed it, actual usage was 6%. The system wasn't broken. The model performed correctly. It was built for a generic company, and this customer's pricing logic, return policies, and ERP integration were anything but generic. That gap is what FDE closes.

FDE origins: from Palantir to the AI era

Palantir, a data analytics firm, first systematized the FDE role. They discovered that even powerful platforms struggle when handed to intelligence agencies, governments, or large enterprises. Users didn't know how to operate them independently. Palantir began placing engineers directly at customer sites, sitting alongside them, learning their business while building usable solutions on the platform. That group became the first forward-deployed engineers.

This model has resurfaced in AI circles over the past two years. Large language models made shipping a working prototype very cheap. They also made something expensive: the gap between prototype and production has grown, not shrunk. OpenAI, Anthropic, and Palantir all hire FDEs at scale for the same reason. Models are generic. Every enterprise's data, permissions, compliance frameworks, and people are radically specific. Bridging that gap requires people on site.

How FDE differs from consultants, systems integrators, and product engineering

When organizations deploy systems, FDE differs from similar roles in how success is defined:

The critical difference lies in that final column. Consultants submit the report and exit. Systems integrators pass testing and exit. Product teams ship the feature and exit. For FDE, success is measured by daily adoption and use. Launch marks the beginning, not the finish line.

When to bring in FDE

Not every project needs FDE. If you're purchasing a tool with clear specifications, standard processes, and it works as documented, placing engineers on-site wastes resources.

FDE delivers real value when several conditions converge: processes deviate significantly from standard and packaged solutions stall at the end; adoption, not technology, is the barrier (the tool exists but the organization won't change established workflows); the industry carries high penalties for failure (financial services, healthcare, manufacturing, automotive) and systems must respect existing compliance and data boundaries; or most commonly, a proof of concept works but can't transition beyond the pilot phase. When these signals appear, placing engineers on-site typically provides better returns than buying another tool.

What FDE does on site

An FDE's day involves three concurrent activities. First is understanding the business: watching how frontline people actually work, where they get stuck, and learning why they won't use the new system. Second is wiring the systems: connecting the model to their ERP, CRM, permissions layers, and real data, handling all the messy details that prototypes skip. Third is driving adoption: adjusting processes, training users, and monitoring usage as the system becomes something they can't work without.

At Tenten, we embed engineers in the customer's operation and take responsibility for systems that run and are used. A polished demo doesn't count. What counts is people actually using the system.