Forward Deployed Engineering: The Complete Guide for Industrial Companies

Forward deployed engineering is defined by three things: where the work happens, what the engineer is responsible for and how long the commitment lasts. All three have to be there. An engineer on site who hands over a report is doing consulting; an engineer who builds remotely to a specification is doing integration.

Where. The engineer works in the client's environment: its offices, job sites, warehouses, mine sites and systems. They learn the workflow from the people who run it every day. The word “forward” comes from military vocabulary, where a forward deployed unit operates in contact with the field rather than from a base in the rear.

Responsibility. The FDE answers for an operational result: files processed, hours given back to the team, errors avoided. They write the code, plug in the connectors, define the rules for handling exceptions and fix things when something breaks.

A product developer brings one capability to many clients; an FDE brings many capabilities to a single client, for as long as it takes to solve its problem. Their work is judged on the result, and the code is only a means. A good FDE even tries to make themselves unnecessary on the problem they solved: if the client needs them again for the same thing, the problem was not really solved.

Duration. The commitment does not end at acceptance. The engineers who built the system run it under the client's supervision, tune it on real data, then move on to the next workflow.

Why context matters more than the specification

A real industrial process holds unwritten knowledge that no document captures. An estimator knows which dimension not to trust on a certain type of drawing. A freight dispatcher knows which customer sends orders without units. A shift supervisor knows which machine reports bad data when it rains.

Traditional software delivery flattens that knowledge into a list of requirements written in a meeting. Forward deployed engineering starts from the opposite premise: context is the scarce resource, and the only way to capture it is to go and get it where the work happens.

The company's nouns and verbs

The first thing an FDE records in a company is its nouns and verbs. The nouns are the objects the organization treats as real: a job, a work package, a structure, a truck, an order, a customer. The verbs are how those objects move forward: how a bid gets approved, what has to be true to close out a progress payment application, who signs off an exception at eleven at night and what happens when that person is on leave.

The same object often carries several names depending on the department. Sales calls it a deal, estimating calls it a project, accounting calls it a cost code and the pricing software calls it a project ID. Each switch from one name to another hides a translation rule, and that is where systems break when someone changes a definition.

Almost none of this is written down. These rules live in the heads of the few people who have been there long enough to stop noticing them, and in a spreadsheet built years ago that the whole team depends on. That is why they are so valuable, and also why you cannot simply ask for them in a meeting: you have to observe them.

The vocabulary to know

The Mirage glossary covers these terms and related notions, such as the AI agent.

Most enterprise AI projects stall between the demo and production. The demo runs on a clean sample; production gets crooked scans, hand-edited Excel files, emails without attachments and cases nobody had mentioned. Forward deployed engineering exists to close that gap.

The problems that standard software, sold identically to a thousand companies, could solve have largely been solved. What remains sits inside the walls: messy, poorly documented workflows that are impossible to understand from a discovery call. That last mile, often a small part of the workflow, still decides whether the rest gets used. It is the ground forward deployed engineering works on.

The model is the easy part

A recent language model can read a drawing, a purchase order or a consignment note. To put it to work in an operation, you have to solve six problems that are specific to each company.

A well-known rule of thumb from enterprise data projects: most of the effort goes into accessing, cleaning and matching data, and only a small part into analysis. AI agents do not change that ratio. They make it more visible, because an agent has to read from and write to the company's critical systems to be useful.

An agent that writes to your systems needs someone on site

A dashboard only reads. An AI agent creates an order in the ERP, proposes a quantity takeoff, prepares a customs declaration or assigns a truck. Each action commits the company. That takes rules written with the people who are responsible for that work today, and a fast correction loop during the first weeks. The AI agents vs RPA comparison explains why script-based automation is no longer enough for these tasks.

AI puts the model within reach of smaller budgets

For a long time, FDE was reserved for multi-million contracts: sending senior engineers to a client for months was expensive. AI tools have changed the equation. An engineer today produces in a few days what used to take weeks, and part of the adaptation work (reading new formats, business rules, interfaces) no longer starts from scratch. Projects once reserved for the very largest accounts are now within reach of mid-sized companies.

It is also what lets Mirage deploy on a shared platform rather than rebuild every project: the engineers adapt proven building blocks to each client's documents and systems.

The simplest way to understand the job is to follow a real week. The example below is a general contractor that wants to speed up its quantity takeoffs and the analysis of its bid packages. The pattern is the same in a mine, a warehouse or a factory.

In practice, the week splits roughly evenly between time with the teams and build work. Time on site varies with the project and the geography, often around half of the time. Two or three well-chosen days on site (an observation, an exception review, a go-live) are worth more than five days of presence with no specific purpose.

Speaking the trade's language

An FDE's effectiveness depends on how fast they learn the client's vocabulary. In construction, they have to handle bid packages, technical specifications, bills of quantities, priced schedules, progress payment applications and change orders without slipping. In a mine: ore grades, haul cycles and equipment availability. In logistics: bills of lading, customs declarations, CMR consignment notes and Incoterms. An engineer who talks about “gaining efficiency” loses the room; an engineer who talks about bid turnaround time and quantity variance rates keeps it.

The guides how to respond to a French construction tender and electrical takeoff from 2D drawings give an idea of the level of trade detail expected.

Reading the room as well as the code

The least visible skill of an FDE is social. They arrive in an organization they do not know, often facing teams that fear being replaced or have already seen IT projects come and go. They have to earn the operators' trust, understand who really decides, and know when to push and when to leave a decision to the client.

That trust is earned with proof. A first useful result within one or two weeks, on the team's real files, carries more weight than a presentation of the project plan. At Mirage, the stated goal is a proof of concept on the client's documents one week after the first meeting.

Looking for the reason nobody gives

When someone blocks a change without a clear reason, they are almost always protecting something they need to do their job. A typical case: a quality inspector refuses a new file format for months, with objections that change at every meeting. An engineer spends a morning next to him and realizes he checks the data by opening the files on his own computer and reading them by eye. The new format took away his only checking tool.

The solution needed neither argument nor escalation: a suitable viewer, built in a few hours, and the migration was approved right after. The inspector would never have given that reason in an interview, because from his point of view it went without saying. Only watching the actual work brings it out.

A solid FDE model rests on two teams working together. The first is in the field and solves one specific client's problem, fast. The second is at headquarters and turns what worked at that client into reusable building blocks for all the others.

The field team writes code that fixes today's problem. It accepts shortcuts to deliver a first result in a few days, because an operator convinced after one week is worth more than a perfect architecture after six months. It does not aim for generality: its job is to get the client's workflow running.

The product team watches what field engineers rebuild from one client to the next: a connector to an ERP, reading a type of drawing, an exception review screen. It turns them into robust, tested, maintained components. Those components then give the field team speed, since it no longer has to rebuild them.

The link between the two teams depends on the quality of the feedback. “It doesn't work” helps nobody. Useful feedback names the type of case that fails, the data that is missing and how often the problem occurs, for example: “structural steel drawings scanned at low resolution make dimension reading fail, on a significant share of this client's drawings”. That level of precision lets the product team improve the system for every client, not only for the one who reported the problem.

The most valuable signal is rarely a feature request. Three clients asking for the same screen is easy to spot and worth little. Three deployments where the engineers work around the same platform limit is the sign that the platform is too narrow for what the field is running into, and that is what has to be widened.

Every shortcut becomes a system to maintain

A script written in an afternoon to unblock a client can still be running a year later, across thousands of operations, without anyone ever having designed it to last. The discipline of an FDE team is to decide, for every fix, whether it joins the platform or is deliberately thrown away once it has done its job. A fix that takes neither path becomes debt, and it is often the client who ends up carrying it.

This loop has a compounding effect. Each deployment makes the next one faster, and each client benefits from what was learned at the others without its data ever leaving its own perimeter.

What this changes for the buyer

The field-product loop is the most important question to ask a provider, because it determines what you will be getting three years from now.

At Mirage, the engineers deploy on the Mirage platform, the shared layer that carries the connectors (more than 200 systems to date), document reading, business rules and supervision. Client-specific work concentrates on what is unique to the client: its documents, its exceptions, its validation rules.

Without a platform, each deployment learns how a company works, delivers a system tailored to it, then loses that knowledge when the engagement ends: the next client starts from zero. That is consulting, often of high quality, but it does not compound. With a platform, every company mapped makes the next deployment faster and the product more accurate.

Who do FDEs report to?

Where forward deployed engineers report says a lot about what you will get. Reporting to sales, they are judged on the current account: sign, expand, renew. Reporting to product, each deployment also has to leave something the next one can start from. Both jobs are useful, but a provider whose FDEs answer only to sales targets is really selling hours.

What protects an FDE provider from its competitors is neither the AI model, which everyone rents from the same supplier, nor the map of a given client, which anyone can sketch in an afternoon. It is the accumulated, current and verified understanding of how companies in a sector really work, built by getting things wrong at clients, being corrected and feeding the correction back into the platform. For the buyer, that makes for a simple criterion: a provider that has already deployed at companies like yours arrives knowing which questions matter.

Forward deployed engineering differs from the other models on one specific point: the provider builds the system, puts it into production and stays responsible for it as long as it runs. The other models stop earlier, or leave operations to the client.

These models are often combined. A consulting firm can identify the workflows to address, an FDE deployment can put them into production, and off-the-shelf software can cover the standard needs around them. No single model answers every problem.

The most common confusion: FDE and staff augmentation

Both put engineers at the client, but responsibility sits in a different place. With staff augmentation, the client directs the work and owns the result. With forward deployed engineering, the provider owns the result: if the system does not process files as agreed, it is up to the provider to fix it.

The comparisons page sets Mirage against specialized software for each trade.

An FDE deployment asks little time of the client company, but it needs the right people at the right moment. Four roles are enough, and a deployment that lacks one almost always slows down.

The implicit commitments

Beyond the roles, three commitments count. Accept that the first weeks of production include corrections: a system that flags its doubts is a system that works. Measure from the starting point, which means knowing the current volumes and processing times. Let the engineers see the real work, including what appears in no procedure.

The system does not take decisions away from the teams. It takes on the repetitive work of reading, data entry and matching, and routes every case that calls for judgment to a person. Operations teams keep control of critical decisions.

An FDE deployment is measured on operational indicators, defined before the start and tracked every week. Mirage tracks the same five measures on every deployment, from the first meeting.

Four rules for honest measurement

Measure the starting point. Without volumes and processing times recorded before the pilot, no gain can be demonstrated. One week of recording is often enough.

Count the exceptions, not only the successes. An automation rate without the reasons for the exceptions does not tell you what to improve. Those reasons steer the engineers' work the following week.

Check quality on a sample. A fast system that gets things wrong costs more than manual work. A regular check of a sample by the business owner keeps the measurement honest.

Prefer a system that flags to a system that improvises. A system that fills the gaps with a plausible answer will never tell you the source data was bad. A system that traces every result back to its source (a quantity to its drawing, an order line to its email) turns each misunderstanding into a visible exception, fixed within the week, instead of an error discovered months later.

The cost of an FDE deployment depends mainly on the number of systems to connect and how varied the documents are, much less on the number of users. At Mirage, the structure is the same for every client: a fixed-price pilot on site, after which the client can stop, then an annual subscription based on the volumes processed. Prices start from $10,000 to launch, then from $1,000 per month; the details are on the pricing page.

The four ways to bill and their effects

What drives the price

The number of systems to connect and their age weigh the most: a recent ERP with an API connects in days, an old business application can take weeks. Then come the variety of documents (a single purchase order format, or hundreds of customers each sending their own), the number of sites and languages, and the volumes processed, which set the subscription. Time on site counts too: an isolated mine requires more travel than a downtown headquarters.

Compare with the cost of doing nothing

The right point of comparison is not the price of standard software, but the current cost of the workflow: hours spent by the team, data entry errors and their consequences, bids not submitted for lack of time, billing delays. The article the true cost of manual order entry gives a calculation method that carries over to other workflows.

An engineer working in your systems and an agent writing to your ERP raise legitimate security questions. They are handled with rules written from the pilot onward, and most are settled in one meeting with IT.

The principles to require from any FDE provider

For the most sensitive environments (infrastructure, defense, critical industrial sites), the deployment can run on isolated infrastructure, with no outbound connection. The strategic systems page describes this kind of deployment.

Mirage's practices are described on the security page, and the terms for large accounts on the enterprise page.

Forward deployed engineering costs more than a standard software subscription and takes time from the client's teams. It only makes sense if the workflow is large enough, specific enough and costly enough today. In several common situations, another option does better.

The forward deployed engineer title has become fashionable and now covers jobs that have almost nothing in common: a presales engineer who shows up at the second meeting, a salesperson who can code, a consultant with a laptop and a purchase order. Many consulting and staff augmentation offerings have adopted it without changing their model. Twelve questions are enough to tell the difference in a first conversation.

The about page presents Mirage, and its case studies the deployments in production.