Field note · Customer education
What is a forward-deployed engineer?
A forward-deployed engineer works inside your organisation for the length of a deployment: watching the actual workflow, choosing the smallest system that fixes it, building it on your infrastructure, and handing it over. This note describes the role, what it is not, and when it is the wrong thing to buy.
- Source
- Written by us. Method and judgement — no statement on this page rests on a fetched document.
- Evidence
- none on this page — it links to the pages that hold it
01The short definition
A forward-deployed engineer is an engineer who works at the customer, on the customer’s problem, with the customer’s data and constraints in front of them. Not a strategist who writes a report. Not a vendor sales engineer who configures a product they also sell. Not a body-shop developer who takes a specification and returns a build.
The distinguishing property is where the person sits during the diagnosis. An FDE spends the first days of an engagement watching how the work is done today — which folder the contracts live in, who re-types the invoice numbers, what happens when the answer is wrong — and only then decides what to build. That order is the whole job.
- ASSESSMENT
We use the term for one role: an engineer embedded with the customer for the length of a deployment, accountable for the system working in production rather than for a document describing it.
BasisOur definition, used consistently across this site’s FDE profiles, deployment reports and enquiry flow. It is a position, not an industry standard.
- ASSESSMENT
The title is not regulated and carries no certification. Treat a claim to it as a claim about method, and ask for the deployments behind it.
BasisNo accreditation body defines the role. Our own verification is a review of submitted deployment reports and evidence, which is what a verified profile on this site means.
02What the work actually is
- 01Observe before specifyingSit with the three people who do the task. Time it. Count the exceptions. Most deployments are decided here, because the thing that hurts is rarely the thing that was described in the first meeting.
- 02Constrain, then chooseWrite down what cannot move: where the data may sit, who may read it, what the answer costs when it is wrong, what the team can operate on a Tuesday afternoon. The constraints eliminate most of the market before any tool is compared.
- 03Build the smallest working versionOne workflow, real documents, real users, in the customer’s environment. A demonstration on sample data proves the model works; it does not prove the deployment works.
- 04Instrument itLogging, an evaluation set drawn from the customer’s own material, and a way to see what the system was asked and what it answered. Without this there is no way to tell a bad week from a broken system.
- 05Hand it overRunbook, access, upgrade path, named owner. An FDE engagement that ends with only the FDE able to operate the system has failed, whatever the demo looked like.
03When you do not need one
Three situations come up repeatedly, and in all three the honest answer is to buy something smaller.
- The problem is a product. If forty people need a better meeting summary and the recordings may sit with a vendor, a seat licence is the correct answer and an engineer is an expensive way to reach it.
- Nobody owns the outcome. If no one internally can say what a good answer looks like, no deployment survives the first disagreement about quality.
- The data is not ready. If the documents are in six systems with no consistent permissions, the first project is access and structure, and that is not an AI project.
- RECOMMENDATION
We recommend starting with a hosted product when the data may leave your network, the workflow is standard, and no internal owner has been named. Revisit the decision when one of the three changes.
BasisRests on the three conditions above and on the cost shape: a seat licence is a monthly cost with no implementation, whereas a deployment is a one-off engineering cost plus running cost. Where your data may sit is the constraint that most often reverses this.
04What it costs, and in what shape
An FDE engagement is priced in days, not in seats. That changes the shape of the cost rather than only its size: implementation is a one-off, and what remains afterwards is infrastructure and maintenance. Every stack page on this site prints both, in a range, with the assumptions listed.
The comparison worth making is not "engineer versus licence" but "one-off plus running cost versus running cost forever, at the headcount you expect in year three".
- ASSESSMENT
We express implementation effort in FDE-days with a low and a high figure, and never as a single number, because the spread between a clean deployment and one that meets its first surprise is the honest part of the estimate.
BasisThe costing model behind every stack and answer page on this site: implementation days × day-rate range, plus infrastructure and model costs, rounded to two significant figures with the inputs printed.