Skip to content
Request a free call
Forward Deployed Engineering · FDE · The role explained

What a forward deployed engineer does

A forward deployed engineer builds software inside a customer's company until their team can run it. Pooya Golchian did this for agentic AI in Dubai.

  1. Frontend
  2. Backend
  3. Linux
  4. DSA
  5. System design
  6. AI engineering
  7. DevOps
  8. Discovery
  9. Business acumen
  10. Communication
See the roadmap
One hand passing a steel relay baton to another in a single beam of light
The work

The job under the title

The title spread through job ads faster than any shared definition of it, and the descriptions still contradict each other. Some read like a sales engineer. Some read like a contractor with a plane ticket. The work underneath is older than the label, and it is specific.

Start with the word deployed. A forward deployed engineer does not wait for requirements to arrive as tickets. They go where the problem is, work inside the customer's systems and constraints, and stay attached until something runs in production. The pattern comes from Palantir and spread through the AI labs, for the same reason in both cases. A platform is general, every customer's reality is specific, and the distance between those two closes in code rather than in a deck.

The role fuses two jobs that most companies keep in separate reporting lines. The first is full-stack delivery. An FDE builds the interface, the service behind it, the data path underneath, and the deployment that carries it all. Most FDEs do it alone, against a date somebody picked for a commercial reason. The second is field work. Requirements arrive as complaints, a half-drawn diagram, and a spreadsheet one person maintains by hand. Turning that into something buildable belongs to the engineer, not to an analyst upstream who hands over a clean brief.

Agency is the trait every job ad gestures at and none of them name. Nobody grooms your backlog. You choose what gets built first and what gets cut. You own the silence when a demo lands flat in front of the customer's executive sponsor. That freedom is the appeal and the cost in equal measure.

Then comes the responsibility people underestimate, and it has grown heavier since agents entered the picture. The FDE proves the system holds. Not that it demos well, that it behaves on a bad input at three in the morning when nobody is watching. A customer who has just seen an agent do something impressive wants to know what stops it doing something expensive. Answering that means evals, guardrails, an audit trail and a tested rollback, built into the delivery rather than promised for a later phase.

Adjacent roles

Forward deployed engineer vs solutions architect

The forward deployed engineer holds the customer relationship and the commit history at once. Almost everything difficult about the role falls out of that one fact. The three roles this gets confused with are each about half of it.

Consultant
A consultant produces judgement. The deliverable is a recommendation, a target operating model, or a decision somebody else will implement. Good consulting changes what a company does, but it leaves no running software behind. The engagement ends exactly where the hard part starts.
Contractor
A contractor takes a scope somebody else defined and builds to it. That is a staffing arrangement more than a role. The scope comes down from a product manager or an architect, the contractor executes it well, and someone settled the ambiguity before anyone signed. A forward deployed engineer comes in because nobody has settled it and nobody internally can.
Solutions architect
A solutions architect draws the system and hands the drawing on. The work is real. It sits alongside a sales cycle, and success means the design gets adopted and the deal closes. Somebody else writes the code. An FDE succeeds only if the software runs, so being in the repository is the job, not an optional extra.
The path in

The roadmap into the role

The roadmap runs engineering first and field skills second, because the market filters in that order. Engineering gets you through the interview loop. Field skills decide whether the engagement succeeds.

This is not an entry-level role. Almost everyone who steps into it is already a full-stack developer with production scars. The title changes where you sit far more than what you can build.

Loading diagram…
The roadmap runs as one spine with two halves. The engineering half moves from frontend and backend, through Linux, into data structures and algorithms with system design, then AI engineering and DevOps. The field half opens at discovery and scoping, meaning requirements gathering and the running trade between scope, speed and quality. Business acumen follows, covering enterprise workflow, return on investment, stakeholder management and the product feedback loop. The half closes on communication and technical writing. The sections below cover each track in full.

The roadmap tracks in full

Frontend and backend, both to production standard

Full stack is the premise here rather than a bonus line on the profile. You build the interface for people who use it in front of you. You also build the service, schema and jobs behind it, with no second team to take either half. Depth beats breadth. Know one frontend framework well enough to debug under pressure, and one backend language you write correctly when tired. Those two, plus honest database fluency, beat a long list of names you touched once.

Linux and the machine underneath

Customer environments run on Linux and they are rarely the tidy ones. Move around a shell without thinking. Read logs. Follow a process to the port it is bound to. Understand permissions, systemd and the network path in front of the service. Work out why the container that ran on your laptop refuses to start on their host. This track stays invisible right up to the moment it is the only thing standing between a working demo and a dead afternoon.

DSA and system design, the first gate

Data structures and algorithms are the first gate in FDE interviews, full stop. If that round goes badly, you never get to show the AI work or the customer judgement. The loop filters there on purpose. Prepare for it on its own terms instead of treating it as an insult to your experience. System design follows immediately and sits far closer to the real work. Scoping a customer system under a latency budget and a data-residency rule is a design interview that never ends.

AI engineering

This track made the role common. It covers agent design, tool use through MCP servers, and retrieval that answers with citations rather than confident prose. It also covers evaluation harnesses that turn a sense of improvement into a number, and enough model serving to run open weights on customer hardware. The bar is not research. The bar is production behaviour under evaluation, a different and much less glamorous skill. The eval suite and the guardrails decide whether an agent works or stays a demo.

DevOps and the cloud

Fluency in at least one major cloud, and the ability to deploy infrastructure as code instead of by clicking. You are often the only person who can put the system somewhere real. The customer's own platform team will read what you wrote and inherit it. Pipelines, secrets handling, observability that answers a question at incident time, and a rollback that has actually been run rather than described in a document.

Discovery and scoping

The first field track, and the one engineers underrate hardest. Requirements gathering has real technique behind it. Ask what happens today rather than what should happen. Watch the work instead of the description of the work. Find the spreadsheet. Find the person everyone quietly routes around. Then sequence what you found so something useful ships early and the riskiest unknown gets attacked first, while it is still cheap to be wrong. Every engagement is a running trade between scope, speed and quality. The forward deployed engineer makes that trade out loud, with the customer, the moment it appears. Making it silently at the keyboard is how a project ends with working software nobody asked for.

Business acumen

You are standing inside somebody's enterprise workflow, and the system you build either fits that workflow or gets politely abandoned two months after launch. Learn how the customer makes money and where the cost actually sits. State the return on what you are building in their terms. A sponsor renews what they can defend to their own boss. Stakeholder management is a first-class task, not an overhead. The person who asked for the work is rarely the person who has to live with it. They often disagree without ever saying so to each other. Then close the loop back into the product, carrying what you learned in the field to the team that builds the platform.

Communication and technical writing

Writing pays back more than any other non-technical skill in this role. You will write the scoping note that quietly becomes the contract, and the architecture memo a platform team reviews without you there. You will write the runbook the on-call engineer opens at two in the morning, and the handover that decides whether your work outlives you. Write so a decision still makes sense to a stranger six months later, with the constraint that forced it recorded next to it. That single habit prevents more rework than any process you can install.

Keep learning, because the field moves

The AI half of this role looked different eighteen months ago and will look different again by the time anyone reads this twice. Model capability, tooling and the patterns that survive contact with production all move faster than any curriculum can track. The durable part is the shape of the work. Build the engineering and field tracks above on purpose, and treat the specific tool list as disposable.

The difference

What it asks beyond senior engineering

Every requirement above exists in ordinary senior engineering. The difference is exposure.

You work without cover

No product manager, no account manager, no sprint to hide a slipped estimate. You tell the person paying, in their building, that day.

Adoption judges you, not the merge

A shipped feature nobody uses is a failure here, even with good code. That changes what you build and in what order, and it stings engineers who judge themselves on craft.

You hold context that has no home

Half of what you learn inside a customer never fits in a ticket. It lives in your head, your notes and your handover. An engineer who cannot write loses most of it on the last day.

You switch environments constantly

New codebase, cloud account and compliance regime each time, sometimes a new language in the room. The role assumes you can work in an unfamiliar repository within a day.

You carry the trust personally

The customer is betting on the person in the room, not software off a shelf. That is why serious interview loops screen judgement as hard as code.

In practice

How I worked this way

I worked forward deployed from 2024 to 2026, mostly in regulated settings. There, data cannot leave the country and every automated decision must stay defensible to a regulator.

As an embedded engineer, I worked inside the client team rather than beside it. I scoped the problem with the people who owned it, then wrote the code in their repository. It deployed on their infrastructure and shipped as code, not as a deck. At handover, their engineers took over with the runbooks and the eval suite.

I worked this way with UAE enterprises. That meant NVIDIA inference on customer premises and Arabic models fine-tuned because an English-first model would have failed the real users. It also meant retrieval that answers in under three seconds and cites its source, so a reviewer can check any claim. Every one of those deployments went to the customer's own team afterwards, which is the part I cared about most.

The method is written down rather than improvised. I run agent work behind specs, evals and approval gates through SpecForge, the open-source lifecycle I publish, which builds on AI-DLC.

Forward Deployed Engineering FAQ

The role, answered

The job, the roles it gets confused with, the interview loop, and the way in.

  • A forward deployed engineer is a senior software engineer who builds inside a customer's company instead of building features for everyone at once. The role merges work most companies split three ways. The engineer scopes the problem with the people who have it. The engineer writes production code in the customer's codebase and deploys it on the customer's infrastructure. Then the engineer stays until the system runs and the customer's own team can keep it running. The pattern comes from Palantir and spread through the AI labs for the same reason. A general platform meets a specific reality at every customer, and somebody has to close that distance in code.

  • A forward deployed engineer ships and supports the software, while a solutions architect designs it and hands the design to somebody else to build. The architect works alongside a sales cycle, and success means the design gets adopted and the deal closes. For the forward deployed engineer, success means the software runs in production. The engineer writes the code, merges it into the customer's repository, deploys it, and owns what happens after the launch call. Both roles sit in front of the customer and both need architecture judgement.

  • Neither, although the role borrows from both. A consultant produces judgement, and the deliverable is a recommendation or a decision somebody else implements. A contractor takes a scope that somebody else defined and builds to it, which is a staffing arrangement rather than a role. A forward deployed engineer defines the scope with the customer and then builds it, holding both ends at once. The distinguishing test is simple. If the engagement ends with a recommendation instead of a running system, it was consulting.

  • Become a full-stack engineer first. Forward deployed engineering is not a beginner role. Most people step into it after several years of shipping frontend and backend code end to end in production. The technical base is full-stack delivery, Linux, data structures and algorithms, system design, and cloud fluency with infrastructure as code. In the current market it also covers AI engineering, meaning agents, retrieval and evaluation. The second half is field skill. That means customer discovery, technical scoping and sequencing, stakeholder management, and writing decisions that still make sense months later. Most candidates arrive with the first half. The second half is where the loop cuts them.

  • A forward deployed engineer needs two stacks, engineering and field. Engineering means frontend and backend to production standard, Linux fluency in environments you did not set up, data structures and algorithms, and system design. It also means at least one major cloud with infrastructure as code, and AI engineering across agent design, tool use, cited retrieval and evaluation harnesses. The field stack is requirements gathering, technical scoping and sequencing, and explicit trade-offs between scope, speed and quality. It also covers the customer's workflow and where their money is made, stakeholder management, and technical writing. High agency runs underneath both, because nobody grooms the backlog.

  • Yes. A data structures and algorithms round opens the loop, before anything else gets assessed. A candidate who fails that coding round never reaches the AI engineering rounds or the customer-facing scenario. Prepare for it on its own terms rather than assuming production experience will carry it. The rest of the loop covers system design and a practical build exercise. It also includes a scenario where an interviewer plays a customer whose requirements do not fit the product.

  • A forward deployed engineer earns what a senior or staff software engineer earns at the same company. The role has no separate pay scale. The technical bar is the same one, and the customer-facing work sits on top of it. Two things push the number up. The role carries travel or on-site expectations. It also sits close to revenue, so equity and bonus pay show up more often than in a purely internal engineering job. Any figure quoted without a market, a company and a level attached is noise. Check published pay data for that company and market instead of a global average.