What a forward-deployed engineer does, and when you need one

"Forward-deployed engineer" is a job title that has spread from a few large software companies into AI and integration work. It sounds more mysterious than it is. A forward-deployed engineer (FDE) is a senior engineer who works inside a customer's team, on the customer's problem, using the customer's systems, until the thing works in production.

This post explains what the role covers, how it differs from consulting and from outsourcing, and when it is a good fit.

The short version

A consultant tells you what to build. An outsourced team builds what you specify, somewhere else. A forward-deployed engineer sits with the people who will use the result, works out what is actually needed, builds it into your existing systems, and stays until your team can run it.

What the work looks like

A typical FDE engagement moves through four kinds of work, often at once:

• Understanding the real workflow. Sitting with operations, sales or support to see how the work is done today, including the spreadsheets and workarounds nobody mentions in meetings.
• Connecting systems. Most of the effort is integration: getting data out of the CRM, the ERP, the ticketing tool or an old database, cleaning it, and writing results back where people already work.
• Building the new piece. That might be an AI workflow, an internal tool, an API or an automation. It is built to the team's standards, in their repositories, with their access controls.
• Handing over. Documentation, runbooks and pairing with the people who will own it, so the system doesn't depend on the FDE staying.

How it differs from other models

None of these is better in general. They fit different problems.

When an FDE is a good fit

• The problem crosses several systems and teams, and nobody owns all of it.
• You know what outcome you want but not exactly what to build.
• Your own engineers are busy with the core product, or you don't have an engineering team.
• You want the result to live in your systems, not in a supplier's platform.
• You are adding AI to an existing process and need it connected to real data with proper access controls, not a standalone demo.

When it isn't

• The requirements are clear and stable. A fixed-scope build is cheaper and simpler.
• Nobody on your side can give the engineer access, answer questions or make decisions. An FDE without a counterpart stalls.
• You need a large team for a long time. That is a staffing question, not an FDE engagement.

What to expect week to week

A hypothetical example: a business wants support tickets sorted and routed automatically, with suggested replies for common questions.

• Week one is spent with the support team and the ticketing system: categories, edge cases, where the data lives, who approves changes.
• Next, a first version runs on a copy of real tickets, with results compared against what agents actually did.
• Then it goes live for one queue, with agents approving every suggested reply, and a weekly review of what it got wrong.
• Finally, the support lead owns the categories and the review, the engineering or IT owner has the runbook, and the FDE steps back.

Each step ends with something working that the team can see, rather than a report.

Questions to ask before you start

• Who on our side is the day-to-day counterpart?
• What access will the engineer need, and who approves it?
• How will we know it is working? Agree a few checks before building.
• What does handover look like, and when?

If that sounds like the kind of problem you have, Systems integration & FDE explains how we run these engagements.