Forward Deployed Engineering: what it is and how an FDE works

In this note · 13 sections

1. What Forward Deployed Engineering is, in one sentence and in detail
2. Where the term comes from
3. What a forward deployed engineer does day to day
4. Forward deployed engineer skills
5. FDE, consultancy and software shop: how they differ
6. What FDE is not
7. A measured case: WhatsApp orders at two distributors
8. How an FDE team works, step by step
9. When it makes sense and when it does not
10. What the client has to bring
11. What Mithandir is and what it is not
12. Primary sources
13. Frequently asked questions

Forward Deployed Engineering (FDE) is a way of working in which software engineers step into the client’s operation to understand a specific problem, build the solution connected to the client’s systems and stay until it runs in production and can be measured. A forward deployed engineer does not wait for a requirements document: they write it, with the people who do the work every day.

This guide covers what it is, what an FDE does, the skills it takes, how it differs from a consultancy and from a software shop, and when it makes sense. We write it from the inside: this is how we work at Mithandir, and at the end we show a case with its numbers. If you are looking for the service, it is at Forward Deployed Engineering.

What Forward Deployed Engineering is, in one sentence and in detail

In one sentence: bring engineering close to the business until the operational problem is solved, not until the software is delivered.

In detail, the model brings together three things that are usually kept apart:

1. Understanding the operation. Who receives the order, who enters it, which system records it, where it gets stuck and why.
2. Building. Software, integrations, automations and artificial intelligence, connected to what the company already uses: its management system, WhatsApp, spreadsheets, the CRM, electronic invoicing.
3. Owning the result. Putting the system in production, watching how people use it, fixing it and measuring whether anything changed.

Talking to the client or writing custom code, on their own, are not enough to call it FDE. What defines the model is that the same team does all three, without handing the problem off.

Where the term comes from

The term became known through Palantir, which calls the engineers who work with each client Forward Deployed Software Engineers. Its official job description covers everything from the first conversation with the client to architecture decisions, data handling, building applications and working with users and executives.

With the arrival of language models, AI companies adopted the same name. Anthropic describes its Forward Deployed Engineer as someone who brings AI applications into the client’s systems, builds pieces such as MCP servers, supports deployment and turns what they learn into reusable patterns. We compare both approaches in Palantir and Mithandir.

The reason for the boom is simple: an AI model delivers nothing until it is connected to the data and rules of a specific company. The model does not make that connection; someone who understands the operation does.

What a forward deployed engineer does day to day

A typical FDE week has little silent coding and a lot of going back and forth between the operation and the system:

• Looking at the work as it is, not as it is documented. At a distributor, that means reading the salespeople’s real messages: pasted lists, voice notes, photos of a handwritten sheet.
• Turning ambiguity into decisions. “The customer wants fernet” is a technical problem: there are two sizes and every customer calls it something different.
• Building inside the client’s environment. Connecting to their management system, read-only when it is in production, and writing only once a person confirms.
• Testing with the people who will use it. Not with a test user: with the person in administration who, until yesterday, typed the orders by hand.
• Measuring and fixing. How often the system proposed correctly, how often a person corrected it, what failed and when it was noticed.
• Writing everything down. Decisions, changes and why they were made, so the system does not depend on a single person.

Forward deployed engineer skills

FDE skills are broader than a developer’s and deeper than a consultant’s. We group them into five:

Skill	What it means in practice
Full-stack software engineering	Building end to end: database, server, interface and deployment, without waiting on another team for each layer
Systems integration	Connecting to an ERP, an API, WhatsApp or an undocumented spreadsheet, so each piece of data is entered only once
Reading the operation	Understanding processes, roles and business constraints, and talking to whoever runs the work as much as to whoever signs
Applied AI with judgment	Knowing when to use a model and when rules are enough; measuring accuracy and corrections; designing what happens when the model is unsure
Ownership of production	Monitoring, alerts, fixing errors and following usage after delivery

On AI projects, the fourth row is what most separates an FDE from a developer. The question is not “which model do I use?” but “what does the system do when it is not sure?”. In our distributors case, the answer was that it does not choose: it asks. If “fernet” can be the 750 ml or the one-liter bottle, it offers both options to the salesperson, and the answer is saved for that customer.

FDE, consultancy and software shop: how they differ

All three can end in a working system. The difference lies in who defines the problem, when the work ends and what each one answers for.

	Forward Deployed Engineering team	Traditional consultancy	Software shop
What it delivers	A process running in production, measured	A diagnosis and a recommendation	The software that was specified
Who defines the scope	The team, with the people who run the process	The consultancy, with management	The client, in a spec
Where it works	Inside the client’s operation and systems	In meetings and interviews	In its own environment
When it ends	When the system is used and can be measured	When the report is presented	When what was ordered is delivered
How it is measured	By the change in the operation	By the quality of the diagnosis	By meeting the spec
Typical risk	Depending on access to users and data	The report never gets implemented	Building well what was not needed

None is better in the abstract. If the problem is clear and the spec is good, a software shop is efficient. If what is missing is deciding what to do, a consultancy may be enough. Forward Deployed Engineering makes sense when the problem sits in between: nobody really knows what to build until they look at the work closely, and whatever gets built has to live alongside systems that already exist.

What FDE is not

There are two readings of the term worth ruling out, because they are the ones that sell most and deliver least.

It is not putting a developer in the client’s office. Physical presence defines nothing. What defines it is access to users, data and decisions. We work remotely with clients in other cities and countries, and the model works the same, as long as those three doors are open.

It is not “adding AI” to everything. Half of an FDE’s work on AI projects is saying no. If what enters the process is already structured, like a bank statement or a work order, rules are enough, and they are cheaper and more predictable. AI is justified when a person writes the data: a voice note, a pasted list, a sentence.

And a third, less obvious one: the work does not end at delivery. It ends when the system keeps running without us watching it all day.

A measured case: WhatsApp orders at two distributors

Vinesco distributes beverages and the other distributes frozen food, both in Rosario, Argentina. Their salespeople send orders by WhatsApp, and someone in administration retyped them, one by one, into the management system. The full case is in WhatsApp orders now load themselves; here we tell the part that is Forward Deployed Engineering.

We did not change the channel. The first idea is always to ask salespeople to use a form or an app. It almost never works: they will keep sending the message, because that is what works for them. So the system sits behind WhatsApp: it reads the message, builds the order against the catalog, and a person confirms it in a panel before it is recorded.

The numbers, measured in the panels’ records:

• At Vinesco, the median time from message to issued order is 7.5 minutes (August 7 to 26, 2026).
• 100% of what was confirmed in Vinesco’s panel was recorded in its management system: 908 of 908 documents between August 7 and September 1, each one confirmed by a person.
• By mid-September, the panel was already issuing 1,216 documents in 30 days.
• At the frozen-food distributor, from September 1 to 9, 59% of order lines went through without anyone touching them.
• Orders, payments, stock transfers between warehouses and quotes went from 4 places to a single inbox.

What using it made us change. One morning there was a recording error that was only discovered at noon. Since that day, every 15 minutes the system checks that everything confirmed was recorded and, if something failed, sends administration a single message with everything together. That kind of decision does not come from a spec: it comes from being close when something breaks.

What we learned from the first to the second. With Vinesco we started in November 2025 and the panel went into production in August 2026. The frozen-food distributor started in March 2026, watching how it worked at Vinesco, and by July it was running on its own panel. What repeated in both is now a product, Mithandir Core. That is the last part of the model: turning what was learned into pieces the next installation does not have to reinvent.

If you run a distributor and want to see whether the same thing happens to you, we put together a page for the industry, WhatsApp orders for distributors, and a calculator for the hours that go into entering orders.

How an FDE team works, step by step

This is how we do it. It is not the only way, but it is the one that has worked for us in production.

1. Discovery inside the operation. Look at the real work before proposing anything: messages, spreadsheets, screens, who does what. The output is a short list of problems, ranked by what they cost.
2. One narrow process first. We pick one that can be measured soon. At the distributors it was order entry, not “the whole back office”.
3. Read before write. We connect to the client’s systems read-only. We write only when a person confirms.
4. Testing with real users. The panel is tested by the person who will use it, with real data, before it is switched on.
5. Production with a safety net. Alerts when something fails, a log of every change and a person who can stop the system.
6. Before-and-after measurement. Time per document, corrections, backlog and usage. If the number does not move, the solution gets reviewed.
7. What repeats becomes a product. And the next company starts closer to the finish line.

At a hair salon chain with locations in three countries, that step-by-step led to a complete switchover in 67 days from the first location, without closing any of them. It is told in the Pelokitos case.

When it makes sense and when it does not

It makes sense if:

• The problem lives in the operation and nobody really knows what to build until they look at it closely.
• The company already has systems it does not want to throw away, and the new pieces have to live alongside them.
• There is no IT department to translate the business into requirements.
• What enters the process is written by a person, differently every time, and that is where AI can help.

It does not make sense if:

• The problem is already specified and only needs building: a software shop will be cheaper.
• There is no access to users or data. Without that, the model does not work, however good the engineering is.
• What you need is a report to decide later.

What the client has to bring

Forward Deployed Engineering is not a service you buy and receive. For it to work, the client has to bring:

• A point person who knows the process and has time to answer.
• Access to the people who run the work, not only to the decision maker.
• Access to data and systems, with the right permissions.
• An agreed success criterion before starting: which number has to change.

On the FDE side there is a technical lead who understands the business, a backlog ranked by impact, clear criteria for going to production and follow-up with a defined scope. Delivering tasks and closing tickets proves development capacity; sustaining the FDE model also means answering for the operational problem.

What Mithandir is and what it is not

Mithandir is a consulting firm based in Rosario, Argentina, that works with the Forward Deployed Engineering approach: an engineering team embedded in each client’s operation, building software, automations and artificial intelligence connected to their real systems. We are not an agency or an hours factory.

It pays to be precise about the comparison. An FDE at Palantir or Anthropic deploys and extends their employer’s technology; we combine tools from different vendors with our own developments, for companies of a different size. The equivalence is one of approach and responsibilities, not of scale. And we split the work across business, management and engineering profiles instead of concentrating it in one person: that is why we speak of a Forward Deployed Engineering team rather than claiming every member is an FDE.

If you want to see whether your operation fits this model, tell us how your company runs today.

Primary sources

• Palantir, official Forward Deployed Software Engineer job description
• Anthropic, official Forward Deployed Engineer job description

The job descriptions were consulted on October 7, 2026 and may change. The case figures come from the records of the Vinesco panel (August 2026) and the frozen-food distributor panel (first weeks of September 2026), published in the case study. The comparison with Palantir and Anthropic is our own analysis.

Frequently asked questions

What does “forward deployed” mean?

That the engineer is deployed on the client’s side, close to the operation, rather than sitting at the vendor’s office waiting for a spec. The phrase comes from military vocabulary: the unit that works at the front, where things happen.

Is an FDE just a developer working at the client’s office?

Not necessarily. What defines it is access: to the people who run the process, to real data and to whoever sets priorities. You can work remotely and be an FDE, and you can be at the office every day and not be one, if all you do is close tickets.

What skills does a forward deployed engineer need on AI projects?

Those of a good software engineer, plus three that weigh double in AI: knowing when a problem does not need AI, being able to measure how often the model gets it right and how often a person corrects it, and designing the flow so that when the model is unsure, it asks instead of guessing.

Is Forward Deployed Engineering the same as staff augmentation?

No. Staff augmentation rents a person’s hours to follow the client’s instructions. A forward deployed team answers for an operational result: it proposes what to build, builds it, puts it in production and measures whether anything changed. If the system is not used, the work is not done.

Can a small or mid-sized company work with a Forward Deployed Engineering team?

Yes, and that is where it pays off most, because smaller companies rarely have an IT department that translates the business into requirements. The distributors in our case have small administration teams: the FDE team does that translation and keeps it up while the system is in use.

How long until there is a result?

A first version to try can be ready in weeks; getting it to work in production takes longer. At the first distributor, nine months passed between the start and the panel in production; at the second one, building on what was learned, four.