A forward deployed engineer (FDE) is a software engineer who works inside a customer's organisation, building and adapting production software against that customer's real data, systems and workflows. Palantir created the role in the early 2010s, and AI companies now hire for it at scale: according to Financial Times data cited by Paraform, FDE job postings grew more than 800% between January and September 2025. An FDE is judged by whether the deployment works for one customer, rather than by features shipped to many.
Where did forward deployed engineering come from?
The role started at Palantir in the early 2010s. Its early customers were government agencies whose data sat in disconnected systems, and those agencies had no internal team able to wire Palantir's software into their operations. Palantir sent engineers to sit with the customer and do that work on site. Internally they were called Deltas, to separate them from Devs, the engineers who built the core product.
Palantir leaned on the model heavily. Paraform's guide to the role cites The Pragmatic Engineer's reporting that Palantir employed more Deltas than software engineers until around 2016. Illinois Tech's summary of the company's own framing is a useful shorthand: a product developer works on one capability across many customers, while an FDE works on one customer across many capabilities.
Enterprise vendors such as Salesforce and Databricks later built similar teams, and the AI labs followed. OpenAI, Anthropic, Google Cloud and Scale AI all hire forward deployed engineers. The reason is practical. A large language model can do many things in general, but it only pays off once someone connects it to a company's documents, permissions and processes. Paraform cites Financial Times data, reported by PYMNTS, showing FDE job postings grew more than 800% between January and September 2025.
What does a forward deployed engineer do day to day?
The work changes week to week, but it always happens close to the people who will use the software. An FDE spends part of the time in meetings with operations staff and part of it writing code against live systems. A typical week mixes these tasks:
- Watching how a process runs today and noting where time, errors and handoffs pile up.
- Writing production code that connects to the customer's data, APIs and login systems.
- Demoing working software to the people who requested it and turning their feedback into the next change.
- Fixing what breaks in real use, such as a failed data sync or an AI prompt that started giving worse answers.
- Reporting repeated patterns back to the product team, so a workaround built for three customers can become a product feature.
What does an FDE deployment look like in practice?
DataCamp's guide describes an FDE rolling out a clinical documentation agent across a hospital network. The engineer connects the agent to the electronic health record system, adapts it to the hospital's own coding conventions, chases down login problems clinicians hit, and rewrites prompts after hearing from doctors. None of that appears in a product demo, and all of it decides whether doctors keep using the tool.
Travel can be heavy. Paraform notes that OpenAI's job description for the role mentions up to 50% travel, and that some FDEs spend most of an early deployment on site before rotating to other clients. For the customer, that presence is the point. Questions get answered in hours, and the engineer sees the spreadsheet everyone relies on but nobody mentioned in the requirements.
How is an FDE different from a solutions engineer, a consultant or staff augmentation?
The titles overlap, and companies use them loosely. DataCamp notes that the FDE role is not standardized across companies, so two job ads with the same name can describe different jobs. The clearest way to compare the roles is to ask who decides what gets built, and whether the person writes production code.
- A solutions engineer (or sales engineer) mostly works before the contract is signed, running demos and proofs of concept, often on sample data. An FDE usually starts after the deal and owns production delivery.
- A consultant studies the problem and recommends a course of action. An FDE writes and ships the code, then stays long enough to see it adopted.
- Staff augmentation adds developers who work from your backlog. Your managers write the tickets, so the result is only as good as the tickets.
- A forward deployed engineer is accountable for an operational outcome. They find the bottleneck, propose the fix, build it and support it in production.
What skills does a forward deployed engineer need?
FDEs are full software engineers first. They need to write, debug and deploy code that holds up in production, and they spend much of their time on integration: APIs, data pipelines, identity and access, and systems the customer has run for years.
The other half of the job is judgment. An FDE has to turn a vague business complaint into something buildable, decide what to customise and what to leave standard, and work without much supervision. For AI work, add retrieval-augmented generation, evaluation of model output, and prompt design to that list. When you interview an FDE team, ask them to walk you through a deployment they ran end to end.
When should a company use forward deployed engineering?
Forward deployed engineering fits when you know the result you want but cannot yet write a detailed specification for it. Typical signs:
- An AI pilot impressed leadership but still runs on test data, because nobody has connected it to real systems and real users.
- The people who understand the process are too busy running it to write requirements or test builds.
- The work touches several systems at once, such as an ERP, a CRM, shared spreadsheets and a messaging channel.
- You have engineers, but they are committed to your core product and cannot spare time for internal operations.
When is a forward deployed engineer the wrong choice?
If you already have a complete specification and a fixed scope, a conventional project build is usually cheaper and simpler. If you need extra hands for a backlog your team already manages well, staff augmentation fits better.
The model also has costs. Embedded engineers are expensive per hour, and Paraform lists heavy travel and burnout risk among the role's trade-offs, which can affect continuity. The bigger risk for a buyer is dependence: if the engineer leaves and nobody on your side understands the system, you are back where you started. Ask for documentation, code in your own repository and training as written deliverables before the engagement begins.
How Safock runs forward deployed engagements
Safock offers forward deployed engineering as a service. It is an AI automation company based in Austin, Texas, and its engineers embed with client teams in the US, the UK, Saudi Arabia, the UAE and Pakistan. Each engagement starts with scoping: the outcomes, the systems involved, who the engineers report to on your side, and whether they work on site, remotely or a mix of both. Scope, milestones and pricing are fixed in a written proposal before work begins.
During the build you see working software from the first sprint and a demo each week, with a running log of decisions and open questions. Access is granted per system and removed when the engagement ends. Handover includes documentation, the code in your repository, training for the people who will run each system, and a support period of 30 days to 3+ months. Cost depends on the number of engineers, the length of the engagement, on-site needs and the systems involved, and a fixed quote follows discovery.