Forward deployed engineer is one of the fastest growing job titles in software right now, and also one of the most misunderstood. Some people hear it and think "consultant with a GitHub account." Others think it is a rebranded sales engineer. Neither is right. This guide explains what a forward deployed engineer actually does, where the role came from, how it differs from the jobs it gets confused with, and how to decide whether you should hire one or bring in FDE capacity from outside.
What is a forward deployed engineer?
A forward deployed engineer (FDE) is a software engineer who works directly inside a customer's business to get software working in that customer's real systems and workflows. They write production code, but the code lives where the customer's problem lives: their data, their tools, their permissions, their edge cases.
The key word is "deployed." A normal product engineer builds one capability for many customers. An FDE builds many capabilities for one customer at a time. They sit close to the people doing the work, watch how it is really done, build the integrations and custom logic needed, and stay accountable until it runs in production.
Where the role came from
Palantir popularized the role. Its early customers were government and intelligence agencies with sensitive, poorly specified problems and messy data. Shipping a product with documentation and walking away did not work. So Palantir embedded engineers with customers to discover the real problem on site and build against it.
Internally Palantir called these engineers "Deltas," and its product engineers "Devs." Palantir has described the difference this way: a Dev focuses on one capability for many customers, a Delta focuses on many capabilities for one customer. The field work then fed back into the core product. Features that FDEs kept building by hand for different customers became candidates for the platform.
Why AI companies are hiring FDEs now
The model sat mostly inside Palantir and a few enterprise software companies for years. Then AI made it mainstream again.
AI pilots tend to look great in a demo and stall in production. The model is rarely the blocker. The blockers are undocumented workflows, data spread across five systems, permissions, evaluation, and the long tail of cases nobody thought about in the pilot. Closing that gap takes an engineer who is willing to live inside the customer's mess.
That is why the large AI labs now run dedicated FDE teams. OpenAI has a Forward Deployed Engineering team that partners with customers to turn research into production systems. Anthropic hires Forward Deployed Engineers on its Applied AI team who embed with strategic customers to ship AI applications. Many AI startups have followed, often listing FDE roles before they have a large sales team, because the deployment work is what turns a signed contract into a renewal.
FDE vs solutions engineer vs consultant vs software engineer
The titles overlap, so it helps to compare them on what each person is actually accountable for.
| Role | Main job | Writes production code? | Accountable for |
|---|---|---|---|
| Forward deployed engineer | Make the product work in one customer's real environment | Yes, a lot of it | The customer outcome in production |
| Solutions or sales engineer | Help close the deal with demos, technical answers and proofs of concept | Some, mostly demos and prototypes | Winning the deal |
| Consultant | Advise on strategy, process or architecture | Usually not | Recommendations and plans |
| Product software engineer | Build and maintain the core product for all customers | Yes | The product and its roadmap |
The simplest test: if the person goes home before the system works in production, they are not doing FDE work. Solutions engineers hand off after the sale. Consultants hand off a document. FDEs hand off a running system, plus the docs and runbooks so someone else can own it.
What an FDE's week actually looks like
No two weeks are the same, but most mix the same ingredients.
- Discovery with the people doing the work. Sitting with operators, recruiters, analysts or support agents to see the workflow as it really runs, not as the process doc says it runs.
- Integration work. Connecting the product to the customer's CRM, ATS, ERP, data warehouse or internal APIs. This is often the biggest chunk of time.
- Building the custom layer. Prompts, agent logic, data transforms and business rules specific to this customer.
- Evaluation and testing. Building test sets from real examples so everyone can see whether the system is getting better or worse.
- Go-live and monitoring. Rolling out in stages, watching logs, fixing what breaks in the first weeks.
- Feedback to the product team. Writing up what had to be built by hand so it can become a product feature later.
Good FDEs are comfortable with ambiguity, can talk to an operations lead in the morning and debug an API integration in the afternoon, and care more about the outcome than about elegant code.
Skills that matter most
- Strong general engineering. Backend, APIs, data, and enough frontend to build a quick internal tool.
- Hands-on AI experience. Prompting, agents, evaluation, and knowing where models fail.
- Customer sense. Asking the right questions, setting expectations and saying no when automation is the wrong fix.
- Ownership. Following problems across team and company boundaries until they are solved.
Hire FDEs or contract FDE capacity?
Hiring FDEs is slow. The profile is rare, competition from the AI labs is intense, and a new hire still needs time to ramp on your product. Contracting FDE capacity is faster but means trusting an outside team with your customers. Here is a practical way to decide.
Hire full-time when
- Deployment work is steady and predictable for the next year or more.
- The knowledge your FDEs gather is core to your product strategy.
- You already have a senior FDE or engineering lead who can hire and coach.
Contract FDE capacity when
- Signed customers are waiting on rollouts and hiring will take months.
- Demand is lumpy, with a few large deployments rather than a steady stream.
- You are not an AI company at all, but you want AI agents built into your own workflows without hiring an AI engineer.
- You want to learn what the role really needs before writing the job description.
Many teams do both. They contract capacity to clear the current backlog and hire full-time once they know what good looks like. Whichever route you choose, insist on clean handover: code in your repo, documented prompts and configuration, and runbooks your own team can follow.
How Remqa uses forward deployed engineers
Remqa is built around forward deployed engineers. We work inside your existing tools, build AI agents and integrations into the way your team actually works, and stay accountable for them running every day. For AI startups we provide FDE capacity on demand for customer rollouts. For recruiting firms we build AI recruiting agents that plug into the ATS and sourcing tools you already pay for. If you want to see where the hours go first, read our map of recruiter hours or our explainer on what AI recruiting agents actually do.
The first step is a free 30-minute hours audit. We look at your stack and workflow and tell you where an engineer, or an agent, would make the biggest difference.