- FDE
What is a Forward Deployed Engineer, and why it works better than traditional consulting
By Apolla delivery team3 min read
Key takeaway
The fundamental difference between an FDE (Forward Deployed Engineer) and traditional consulting is accountability: consultants deliver a plan and leave, while an FDE is accountable for the system running in production. Palantir invented the model in the 2010s, and OpenAI and Anthropic adopted it after 2024. The typical time to value is 3–9 months, and an MVP for a key scenario usually takes 2–4 weeks.
What an FDE is
FDE is a delivery model. Engineers embed in the customer's real environment and, under real constraints and production data, write code, build pipelines and handle edge cases. They own the whole path end to end, from problem discovery through architecture and integration to production go-live, until the system actually runs. Palantir used this model to deliver complex data platforms into governments and large enterprises; OpenAI and Anthropic built FDE teams after 2024 to deliver LLM capabilities into specific business processes inside enterprises.
How it differs from consulting and outsourcing
The difference between the three models is not the caliber of the people. It is accountability and where the work happens. Consulting delivers a plan; the output is a document. Outsourcing delivers code; the output is software that matches the requirements document. FDE delivers business results running in production.
- Traditional consulting: a one-off plan, gone on delivery; results rarely turn into product; distant from the production environment
- Outsourced development: code delivered against a requirements document; if the document is wrong, the code is still "correct"
- FDE: on-site co-creation, staying until it "actually works"; lessons feed back into standardized product capabilities; direct exposure to real data and production constraints
Why AI projects especially need FDEs
AI requirements are hard to state in one pass. Business teams often do not know what they really want until they see the first prototype, and the true state of the data cannot be assessed until it is connected. Studies of successful AI deployments consistently find they were built iteratively rather than in a single waterfall pass. That is exactly how the FDE model works.
- 2–4weeks
- MVP cycle for a key scenario
- 3–9months
- From scenario discovery to stable production
- 100–300questions
- Evaluation set before go-live
Apolla delivery statistics
The five-stage FDE loop
Discovery: go deep into the business, identify real problems and high-value scenarios. Prototype: quickly build a verifiable prototype on real data. Deploy: handle edge cases and push through to a stable production environment. Productize: distill common patterns into standardized product capabilities. Scale: feed those capabilities back into the platform and reuse them across more scenarios.
What the customer needs to commit
One business-side counterpart (knows the process, can make decisions) and one IT-side counterpart (owns systems and data interfaces). The FDE team handles day-to-day development, and the code and documentation belong to the customer.
Which scenarios suit FDE
Critical, complex, cross-system scenarios with high value. Scenarios whose requirements cannot be stated in one pass and need co-creation to clarify. Scenarios that must be validated fast and pushed to production. Scenarios the enterprise wants to turn into its own AI capability. Conversely, for highly standardized scenarios with mature templates, configuring a template and going live is the better deal.