TL;DR
A forward deployed engineer (FDE) is a software engineer who works inside a customer’s team instead of behind a product roadmap. They learn how the business runs, find the problem worth solving and ship the code to production themselves. Most guides explain the role to job seekers. This one is for the company on the other side: what an FDE actually does on a project, how it differs from a solutions engineer or a consultant, and when you need one.
I’m Denys, a senior full-stack and AI engineer in Porto. I work as a forward deployed engineer for small teams, so I describe the role from the inside. The examples below come from my own projects; the market numbers come from the sources linked next to them.
What is a forward deployed engineer?
A forward deployed engineer is a software engineer who is placed with the people who use the software, writes production code for their problem and owns it until it works. The word “forward” is the point: the engineer works where the problem is, not at a distance from it.
The title comes from Palantir. Its FDEs were called “Deltas”, and until 2016 the company had more of them than regular software engineers, as The Pragmatic Engineer reports. Palantir sums the job up as similar to a startup CTO: a small team that owns end-to-end execution of a high-stakes project. OpenAI’s posting describes engineers who “own discovery, technical scoping, system design, build, and production rollout” with its customers.
The role is spreading fast. Bloomberry’s analysis counted 1,165% more postings with the FDE title from January to October 2025 than in the same months of 2024. The usual explanation is AI: a model is easy to try and hard to fit into a real business, and fitting it is exactly this job.
What does a forward deployed engineer actually do?
The work is a loop, and most of it happens before any code is written.
- Learn how the work is really done. Sit with the people who do it, read the spreadsheets they use, see where things break.
- Find the problem worth solving. Often it is not the one in the first call.
- Build it into production. Real data, real users, real access rules, not a demo.
- Stay until it works. Fix what users hit in the first weeks, then hand over or keep going.
Job postings say the same. In the 1,000 postings Bloomberry analyzed, working directly with customers was the most common responsibility (55%), followed by building and deploying AI/ML systems (37%) and integrating systems and APIs (32%). No posting listed a sales quota as a core duty. Time on site varies: Palantir expects about 25% of an FDE’s time with customers and the healthcare startup Commure up to 50%, according to The Pragmatic Engineer.
Is every “forward deployed engineer” the same job?
No. The title now covers three different jobs, and the difference matters when you hire or buy one.
- The builder (60% of postings). Embeds with the customer and writes most of the code: 70 to 90% of the time, by Bloomberry’s markers.
- A sales engineer under a new title (30%). Runs demos and proofs of concept, then hands the build to an implementation team.
- An internal tools role (10%). Builds automation for the company’s own sales and marketing teams; the “customer” is internal.
If you need something built and running, you want the first kind. Ask one question to tell them apart: who writes the code that goes to production?
What does it look like on a real project?
Two of my projects show the loop better than a definition.
Construction documents. A construction team ran documents, forms and site reports in Google Sheets and Docs, and site updates reached the office late. The obvious request was “an app instead of spreadsheets”. Sitting with the workflow showed the real constraint: spreadsheets could go only if each role saw exactly what it should and each company’s data stayed its own. So the access rules went into the database itself, and the platform was built around them: forms filled on site with photos and a signature, approval, automatic PDFs, trackers and a client portal. The case file is at /work/construction-document-platform/.
Live-broadcast audio. A media operations team checked commentary audio by hand, so a missed fault could reach viewers. The first idea was simple alerts. The real requirement, found by looking at how operators work, was that alerts must be complete and quiet. Complete: a network drop must not lose readings, so the site machine keeps an hour of readings and a day of events on disk and re-sends them. Quiet: a flapping channel must not flood operators, so an alert fires only after a fault lasts a minimum time. The case file is at /work/live-broadcast-audio-qa/.
In both cases the code was the smaller part. The value was in finding the constraint that the first request did not mention.
How is an FDE different from a solutions engineer or a consultant?
The test is who writes the code and who answers for it in production.
| Forward deployed engineer | Solutions engineer | Consultant | Product engineer | |
|---|---|---|---|---|
| Works with | The customer’s team, often on site | The customer during the sale | The customer’s management | The internal product team |
| Main output | Production code for this customer | Demos and proofs of concept | Recommendations and plans | Features for all customers |
| Writes production code | Yes, most of the time | Some, then hands off | Rarely | Yes |
| Owns the result in use | Yes | No, implementation does | No | For the product, not one client |
| Measured by | The customer’s problem solved | Deals won | Advice delivered | Product roadmap |
The Pragmatic Engineer puts the line in the same place: FDEs work with customers and also contribute to the product, while solutions architects and sales engineers stay closer to the sale.
When does a company need a forward deployed engineer?
When the problem is not fully defined yet and the person who finds it should be the person who builds it. Typical signs:
- The work runs on spreadsheets, email and manual checks, and nobody has written down how.
- You are adding AI or an integration to a process with messy data and real users.
- Requirements change every week, so a fixed specification would be out of date before it ships.
- Past projects failed between the people who understood the business and the people who wrote the code.
You probably do not need one when the specification is clear and stable, or when the job needs many roles at once, such as design, mobile and QA in parallel. A team or an agency covers that better.
How do you get one?
There are three common routes. You can hire an FDE in-house, which takes months: about 3 to 7 by my sum of cited ranges in the hiring timeline. You can bring in an agency, which usually separates the people who sell from the people who build. Or you can embed one senior engineer on a subscription, which is how I work. Forward deployed engineer vs agency vs freelancer compares the options side by side, including when each one is the wrong choice.
Frequently asked questions
What does FDE stand for?
Forward deployed engineer. The title started at Palantir and is now used by OpenAI, Databricks, Ramp, Salesforce and many AI startups.
How much does a forward deployed engineer earn?
In the US, Bloomberry’s markers for the builder type are USD 140,000 to 250,000 a year in salary, usually with equity. The sales-engineer type is USD 120,000 to 200,000 plus commission. Both ranges come from postings from 2025, so treat them as a guide, not a quote.
Is a forward deployed engineer a sales role?
Not the builder type. In Bloomberry’s sample no posting made revenue a core duty. FDEs often help a sale close by showing that the product can be made to work, but the job is engineering.
Can an FDE work remotely?
Partly. Learning a business is faster in the room, which is why postings mention 25 to 50% time with customers. For software-only work, a shared chat, screen sharing and access to the real data cover most of it, with visits when the work needs them.
Thinking about an FDE for your team?
If you're working out whether the role fits your problem, I'm happy to compare notes. No pitch.
Get in touch