A forward deployed engineer is a software engineer who works directly with a company's biggest customers and writes the code that makes the product work with their systems. Job adverts for it have multiplied in the last couple of years, and it sits in an odd spot between engineering and customer work.
What the job is
The usual title is forward deployed engineer, or FDE (you will also hear 'forward deploy engineer'). Palantir made the role famous. It calls these engineers Forward Deployed Software Engineers, or 'Deltas' internally, and calls the engineers who build its core platforms 'Devs'.
Palantir sums up the difference in one line. A Dev's focus is 'one capability, many customers'. A Delta's focus is 'one customer, many capabilities'. A product engineer builds a feature once and ships it to everyone. An FDE takes the whole product to one customer and makes it useful there.
In practice that means:
- joining sales and kick-off calls to hear what the customer needs;
- learning how the customer's systems fit together, and where the data lives;
- writing integrations, scripts and small services that connect the product to those systems;
- building quick prototypes on the customer's real data;
- fixing deployment problems inside the customer's environment;
- telling the product team what keeps coming up.
The name borrows the military idea of forward deployment: you work at the front line, close to the problem, rather than back at headquarters. At some companies that means sitting in the customer's office for days at a time. At others most of the work is remote, with regular visits.
Why a good product still needs one
A product team builds for many customers at once. It has to, or it would never ship anything. So it makes reasonable guesses: customers will use one of the popular login providers, their data will be in a database the product already supports, and their network will let the product reach the internet.
Large companies break those guesses all the time. Each one has its own tools, its own rules and its own security demands. A bank may forbid any data leaving its network. A hospital may need every action logged for an audit. A manufacturer may run a key system that is fifteen years old, with no API at all and a vendor that no longer exists.
Each of these is a gap between a product built for the average customer and one specific, very large customer. Closing those gaps takes code, and the person who writes that code needs to understand both sides: how the product works inside, and how the customer works in practice. That person is the FDE.
A worked example
Say a startup sells a platform that reads incoming invoices, pulls out the totals and flags anything unusual. A large logistics company wants it, and the deal is big enough to matter for the whole year. In the first sales call, their IT team lists what it will take:
- Staff must sign in with the company's own login system, not a separate password.
- Invoices arrive in an old warehouse system that can only export a CSV file each night.
- Results have to go back into their finance database, which the product doesn't support.
- Their security team must approve anything that touches supplier data.
The FDE joins that call and the next few. They map out the customer's systems, then get to work. Week one, they connect the product to the company's single sign-on, so staff log in with their work accounts. Week two, they write a small job that picks up the nightly CSV, cleans up the warehouse system's odd date format and feeds the rows into the product. By the end of week two the customer's finance team is looking at their own invoices in a prototype, not a demo with made-up data.
Then the deployment stalls. The product runs inside the customer's network, and a firewall blocks the calls it makes to an outside service. The FDE works it out with the customer's network team, changes the configuration and gets it running. Finally they write a connector that sends the results into the finance database, and walk the security team through what data goes where.
Afterwards, the FDE tells the product team what they built. The CSV import and the finance connector are probably useful to other customers too, so they become product features. The firewall fix becomes a line in the setup guide. That last step is what separates an FDE from a contractor: the next large customer needs less custom work.
How it differs from the roles around it
The role borrows from support, sales and product engineering, which is why people mix them up.
| Role | Main focus | Writes production code? |
|---|---|---|
| Product engineer | One feature, for every customer | Yes, in the product |
| Forward deployed engineer | One customer, every part of the product | Yes, around the product |
| Solutions engineer | Showing the product can fit | Mostly demos and proofs |
| Support engineer | Fixing problems after launch | Sometimes, for fixes |
A solutions engineer (also called a sales engineer or solutions architect) helps win the deal: demos, technical questions, a proof of concept. Their work usually stops at 'yes, this can fit'. An FDE carries on past that point and builds the thing that makes it fit, often on the customer's own systems.
A consultant is the other common comparison. Palantir's own engineers draw the line like this: a consultant often delivers a one-off analysis or recommendation, while an FDE deploys an existing product and builds something the customer keeps using. The FDE can also get the product itself changed, because they work with the team that builds it.
If you have seen our video on business analysts, the FDE does some of the same listening and requirement gathering, then writes the code as well.
Why the role is everywhere now
The role isn't new. Palantir has worked this way since its early days with government and defence customers. What changed is that AI products made the gap between 'it works' and 'it works here' much wider.
An AI tool that summarises documents is only useful once it can reach the company's documents, respect who is allowed to see what, and fit into how people work. Every company's documents, permissions and workflows are different. So AI companies, including OpenAI and Anthropic, have been hiring forward deployed engineers to get their products running inside large customers. If you want to see what building those AI products involves, our AI engineering video covers it.
There is a business argument behind it too. The venture firm a16z has argued that startups should accept lower margins and spend money on deployment work like this, because a product that is wired deep into a customer's systems is hard for a rival to replace. That only works if the custom work feeds back into the product. If every customer needs a fresh pile of one-off code, the company has turned into a consultancy without meaning to.
What the job asks of you
An FDE needs a wide skill set more than a deep one. The technical side covers APIs and integrations, databases, authentication, networking basics and deployment, because any of those can be the thing that blocks a customer. You don't need to be the best in the room at any one of them, but you do need to find your way around an unfamiliar system quickly.
The other half is people work. You will explain technical trade-offs to non-technical managers, push back when a request doesn't make sense, and keep a customer calm when something breaks in front of them. Many FDEs also travel, and switch between very different industries from one project to the next.
It suits people who like variety and want to see their code in use the same week they write it. It is less of a fit if you want long stretches of focused work on one well-designed system. Reports from people in the job say some FDE roles drift towards sales support or consulting, with little software engineering, so ask in the interview how much of the week goes on code.
Common mistakes
- Forking the product for each customer: a copy of the codebase per customer is quick at first and painful forever. Build on top of the product through its APIs and settings where you can.
- Saying yes to everything: some requests should become product features, some should be declined, and some just need a workaround. Deciding which is part of the job.
- Leaving security until the end: a security review that starts in week six can undo five weeks of work. Bring the customer's security team in early.
- Shipping the prototype as the final system: a prototype proves the idea. The version the customer depends on needs tests, monitoring and someone who owns it.
- Keeping it all in your head: if the customer's setup only lives in one FDE's memory, the next person starts from zero. Write down what you built and why.
Key takeaways
- A forward deployed engineer is a software engineer who works close to customers and makes the product fit their real systems.
- Product teams build one capability for many customers; FDEs make many capabilities work for one customer.
- The work is integrations, prototypes and deployment fixes, alongside sales calls and lots of listening.
- Good FDEs feed what they learn back to the product, so each customer gets easier than the last.
- AI products need deep access to a company's data and permissions, which is why the role is in such demand now.
