What a Forward Deployed Engineer actually does
My title is Forward Deployed Engineer, and most people who read it ask the same thing: is that a sales job or an engineering job? It is an engineering job. What changes is where the engineering happens.
Forward Deployed Engineer, in one sentence
A Forward Deployed Engineer (FDE) is a software engineer who works inside a customer's environment, on that customer's actual problem, and ships production code into the systems the customer already runs.
The rest of this post is what that means in practice, from the work I have done under the title since April 2022.
Where the title comes from
Palantir coined it. Instead of building one product at headquarters and handing it over, they sent engineers to sit with the customer and build what that customer needed on top of the platform. The "forward" is borrowed from the military sense of a unit deployed close to where things happen rather than at the base.
The title has travelled a long way since. AI companies in particular now hire Forward Deployed Engineers, because getting a model to work inside a company's real data, permissions and workflows has turned out to be harder than the model itself. The problem is old, though. Any product sold into a business eventually has to meet the systems that business already runs on, and somebody has to make that meeting work.
What the work looks like
I run my own practice, Luumtech. The clients have included a foundry, a mining company, a rug brand and an education foundation here in Turkey, and companies in Germany, the Netherlands and Switzerland. Alongside it I have worked remotely for a team in the Netherlands on payment and marketing integrations, and for a Shopify-focused startup in Australia.
The industries differ. The shape of the work rarely does:
- An ERP that needs a module it was never designed for. The business has outgrown the screens it was sold, and the data model underneath is older than anyone currently working there.
- Two platforms that were never meant to talk to each other. A store and a warehouse, a CRM and an accounting package. Webhooks in one direction, a sync job in the other, and the queues and retries that keep it standing when one side goes quiet.
- A payment flow. Gateways like Stripe and Revolut wired into the rest of the business, so that a transaction does not need a person to copy it from one screen to another.
- An MVP that has to survive real users. Built fast, but on the assumption that it will still be running a year later.
The work is usually half engineering and half conversation. Someone describes what they need, and the real constraint turns out to be three layers down: a field that means two different things in two departments, a nightly export nobody remembers setting up, an API limit that only bites at month end.
How an engagement usually runs
- Learn the system before proposing anything. Read the schema, the logs and the export files, and sit with the people who use it every day. The fastest way to waste a month is to design against the system as it was described rather than as it is.
- Find the constraint behind the request. The request is usually a symptom. "We need a report" often means "two systems disagree and nobody knows which one is right."
- Ship the smallest thing that runs in production. Not a demo. Something that touches real data, even if it only handles one case.
- Make it boring. Idempotent webhook handlers, retries with backoff, alerts that fire before the customer notices, and a log that explains what happened without me in the room.
- Hand it over. Whatever I build has to keep working long after I stop looking at it, so the last step is making sure it does not need me.
Forward Deployed Engineer vs full stack developer
These two get confused because most FDEs are full stack developers. Full stack describes your skills. Forward deployed describes where you apply them. A full stack developer can spend a career on one product without ever meeting a customer; a Forward Deployed Engineer spends most of the job inside someone else's systems, and is judged by whether those systems work afterwards.
I use both titles for that reason. The skills are full stack: Next.js and React on the front, Node.js, Laravel, PostgreSQL, Redis and Docker behind it, Flutter when it has to be on a phone. The job is forward deployed.
Forward Deployed Engineer vs solutions engineer and software engineer
| Forward Deployed Engineer | Solutions engineer | Product software engineer | |
|---|---|---|---|
| Works for | One customer at a time | The sales process | Many customers through one product |
| Production code | Yes, in the customer's systems | Rarely; demos and proofs of concept | Yes, in the product |
| Usually starts | After the deal is signed | Before the deal is signed | Independently of any one deal |
| Judged by | The customer's system working in production | Deals won | Product quality and velocity |
The lines blur at small companies, where one person may do all three. A useful test: if the role never touches production, it is a solutions role, whatever the title says.
The skills that matter
- Integration fluency. REST, GraphQL, webhooks and OAuth, and the patience to read someone else's API documentation closely. Much of my Shopify work was exactly this: app installation flows, billing and webhook processing on the platform's GraphQL APIs.
- Reading other people's data. SQL, and the habit of asking what a column really means before trusting it. ERP schemas are rarely what their names suggest.
- Reliability as a default. Queues, retries, idempotency and monitoring. A customer forgives a missing feature far more easily than a payment that silently did not sync.
- Explaining things. My first taste of this was a developer relations internship at Huawei, running workshops for developers adopting HMS SDKs. Translating between what a system does and what a person needs is half the job.
- Learning a domain quickly. For my graduation project I built a production recipe optimizer for a silica sand facility, which meant learning how that plant actually blends its product before writing a line of the model.
Forward Deployed AI Engineer
Many FDE openings now sit on AI teams, sometimes under the title Forward Deployed AI Engineer. The work centres on LLMs, retrieval and agents, but the hard part is the familiar one: connecting the model to the customer's data, permissions and workflows, and making the result reliable enough that people trust it. If you have spent years integrating systems, you already have most of what that job needs.
Forward Deployed Engineers in Turkey
The title is still rare here. Plenty of engineers in Turkey do this work under other names, such as integration developer, ERP consultant or solutions developer. That is starting to change as international companies with teams in Istanbul open roles under the FDE title, and as Turkish engineers work remotely for teams abroad, which is how much of my own work has gone. If you are hiring for the role in Turkey, expect most candidates to recognise the work before they recognise the title.
How to become a Forward Deployed Engineer
- Get production scars first. The role assumes you have shipped software and stayed responsible for it after it went live. Full stack experience is the usual way in.
- Take work where you face the customer. Freelancing, an agency or a practice of your own all force the conversation half of the job.
- Build integrations, not only greenfield apps. Connecting two imperfect systems teaches more about real software than starting a clean one.
- Write things down. Specs, runbooks and handover notes are part of the deliverable.
- Show deployments, not demos. A portfolio that explains what ran in production, for whom, and what changed is stronger than a list of frameworks.
Frequently asked questions
What does FDE stand for?
Forward Deployed Engineer. Some companies say Forward Deployed Software Engineer; the role is the same.
Is a Forward Deployed Engineer a sales role?
No. An FDE may join customer calls and may help close a deal, but the job is measured by production systems that work. Pre-sales demos and proofs of concept are usually a solutions engineer's job.
Do Forward Deployed Engineers work on site?
Sometimes. Some of my work has been on site in Istanbul, and some has been fully remote for teams in the Netherlands and Australia. What matters is access to the customer's systems and people, not the building.
Who is the role a good fit for?
Engineers who enjoy messy, real constraints more than clean greenfield work, who are comfortable talking to the people who use the software, and who would rather see one system work properly than ship ten features nobody uses.
If you have a system that needs to talk to another one, or a product that needs to work inside a customer's stack, I would like to hear about it.