What a Forward-Deployed Engineer Does and When You Need One

A forward-deployed engineer is a software engineer who works inside the customer's process instead of behind a backlog. They sit with the people who will use the tool, learn how the work is actually done, build the first version against real data, and stay until it runs in daily operations. The title comes from companies that sell complex software to large organisations, where a product only works once someone has wired it into the customer's systems and habits.

The same way of working fits small and mid-sized companies, maybe better. A small business rarely has an internal IT team that can translate a vague idea ("can AI read our supplier certificates?") into a specification. It needs one person who can do the discovery, write the code and own the outcome.

What the role actually does

Most of the job happens before and after the code. A typical engagement goes through four phases:

• Discovery. Interviews with the people who do the work, a walk through the real documents, spreadsheets and systems, and a written description of the current process with its exceptions. The exceptions matter most, because that is where automation breaks.
• Prototype. A working tool on a sample of real data within days, not a slide deck. It is rough, but people can click it and say what is wrong.
• Production. Access control, error handling, logging, monitoring, backups, a review step where a person approves uncertain results, and a test set that shows whether the tool still works after every change.
• Handover and support. Documentation, a short training for the team, and an agreed way to report problems and request changes.

How it differs from a classic project

In a fixed-scope project the customer writes requirements, the vendor builds to them, and both sides argue about what the requirements meant. That works when the problem is well understood, like a new website or a known integration.

AI automation is rarely well understood at the start. Nobody knows how many invoices have a strange layout, how often a supplier sends a scan instead of a PDF, or which rule the accountant applies without writing it down. A forward-deployed engineer finds this out by working with the material, so the scope is shaped by evidence instead of guesses.

It also differs from staff augmentation. An augmented developer takes tickets from your team lead. A forward-deployed engineer is expected to decide what should be built, push back when an idea does not pay off, and measure whether the result works.

When a small business needs one

The model makes sense when several of these are true:

• a repetitive process eats hours every week: reading documents, copying data between systems, checking deadlines, answering the same questions;
• the data sits in many places: ERP or 1C, Excel files, email attachments, shared folders, scanned paper;
• someone already tried a chatbot or a ChatGPT prototype and it works in a demo but not on real cases;
• there is no internal developer who knows both the business and the technology.

It makes less sense when the process changes every month, when there is no one on your side who can spend a few hours a week answering questions, or when an off-the-shelf tool already does the job. In that case buy the tool.

What to expect in the first two weeks

We start our engagements with a fixed-price block of two weeks. By the end of it you should have three things: a written map of the process with the exceptions found in real data, a prototype that runs on a sample of your documents or records, and an honest estimate of what production would take, including what should not be automated at all.

After that you decide whether to continue. A full engagement usually runs two to six weeks, depending on how many systems are involved and how much review the results need.

Questions to ask before hiring one

• Will the engineer work with our real data from the first week, and how is access controlled?
• How will we know the tool is correct? Ask for the test set and the metric, not a promise. Our notes on evaluations and human review describe what that looks like.
• Where do the models run, and does any of our data leave our infrastructure? For confidential files see local AI for confidential documents.
• What happens after handover: who fixes it when a supplier changes their invoice layout?

If the answers are vague, the project will be too. If you want to talk through a concrete process, our forward-deployed engineering page describes how we run these engagements, and you can reply to us through the contact form.