Glossary
What is a Forward Deployed Engineer?
An engineer you find at the customer's office rather than their own. They map how the work actually happens there, decide where AI belongs at all, and then build it. Palantir made the role well known, and it's now one of the most sought-after positions in technology.
The short answer
A forward deployed engineer is the role that connects what the technology can do with how a specific company actually operates. Not a consultant, because they write code. Not a classic developer, because half the job happens in the customer's office, talking to people.
The term is military in origin: a forward deployed unit doesn't wait at base for the mission to arrive, it goes to the field. Same logic — the customer doesn't come to the product, the engineer goes to the customer.
Why this became the role everyone wants
A few years ago the question was who would have access to the good models. Today every company can buy the same ones. Look at the stack at fifty enterprises and you'll find roughly the same thing.
If everyone has the same base capability, then intelligence is no longer the moat. The advantage moves to who can embed it, and where. That isn't a model question. It's a process question — and a people question.
The three stages of the work
1. Understand how the work really happens
This takes the most time and gets underestimated the most. Every company does the same thing differently. At two similar-sized firms, processing supplier invoices is ten steps at one and thirty at the other; one runs Salesforce and Gong, the other HubSpot and Clay. And the exceptions — what happens when something breaks — are almost never written down anywhere.
We wrote about this separately: the documented process and the real one.
2. Decide where intelligence belongs — and where it doesn't
This is the FDE's judgement, and it's the most valuable part of the role. In a ten-step workflow, typically two or three steps need real judgement. The rest is solved faster, cheaper and more reliably with deterministic software.
"Don't touch this process at all" is also a legitimate answer: too risky, too little return, or already automated.
3. Build it and get it live
How much actual coding this means varies enormously. Sometimes you configure an existing platform and the code amounts to SQL. Sometimes you write production systems. What's constant is that when something breaks in production, your name is on it — you need to know what to do.
Why it's hard: two professions in one person
An FDE is not the average of the two skill sets, and definitely not assembled from the weaker half of each. A good FDE is strong on both sides — which is why they're rare, and why they're expensive.
What a good consultant brings
The business side
- Mapping workflows by observation, not survey
- Reading cost, risk and incentives
- Getting a system adopted inside an organisation
- Navigating internal politics and sponsors
- Stating business value in numbers
What a good software engineer brings
The engineering side
- System design, APIs, data models
- Agents, tool use, context management
- Evals, guardrails, failure modes
- Reliability, logging, monitoring
- Production code and operations
The market is full of "FDEs" who aren't strong on either side. This role produces value when one person carries the business understanding all the way through to working software.
When is it worth hiring an FDE?
- You have a process that burns a lot of manual hours and nobody can say exactly how many steps it has.
- You already ran an AI pilot that worked in the demo and not in production.
- Your internal dev team has no capacity to spend weeks mapping another department's process.
- You need to tell the board, in numbers, what an AI investment returned.
If any of those sound familiar, look at how we work, or get in touch.
Frequently asked questions
Is an FDE the same as a solution architect?
No. A solution architect typically designs and hands the build to someone else. An FDE is the same person who mapped the process, wrote the code, and owns it in production. The information loss between design and implementation is exactly what this role removes.
Why does it need on-site presence if remote works?
In a one-hour video call you get what your colleague thinks their job is. Sitting next to them for a full day you get what the job is — including the moment something breaks and they fix it by instinct, with that fix documented nowhere. We work hybrid: discovery on site, building mostly remote.
What does an FDE cost in Hungary?
Internationally this is one of the best-paid roles in technology. In Hungary both day-rate and embedded arrangements are available; we publish real bands on the pricing page.
We have our own dev team. Do we still need an FDE?
Often that's exactly when it helps most. An internal team knows the systems, but rarely has weeks free to map another department's process — and rarely has practice evaluating a non-deterministic system. In most engagements the FDE works with your team, not instead of it.