When does a company actually need an FDE?

Short answer: you need a forward deployed engineer when the requirement is vague, when it spans several systems you already run, or when a first attempt never reached production. If instead the requirement is standard, a mature product already covers it, you can write a specification a developer can follow, or what you want is steady execution capacity — do not hire one. Buying a product, hiring your own engineer, or buying capacity by the day will all be cheaper.

The question is not whether you should “use AI”. It is whether your problem is an execution problem, where what to build is settled, or a definition problem, where it is not. Forward deployed engineering only pays for the second kind.

Signals you do not need one

Hit any of these and be sceptical of anyone selling you an engineer on site.

1. The requirement is standard. Existing products cover it, and adapting your process to the product is usually cheaper than custom development.
2. You can write the specification yourself. Somebody already knows what should be built. What you lack is build capacity.
3. Someone in-house can decide what to build, to what standard, and who signs it off. That judgement is the core of the role — see what a forward deployed engineer actually does. If you already have it, do not buy it.
4. You want steady execution capacity. Iteration, maintenance, testing, data preparation. Buying that by the day is the most economical arrangement.
5. Your budget only stretches to “send someone to write code”. It does not cover a diagnosis and a bounded pilot first. When the money can only buy hours, hours are what you get.

If any of those is true, the difficulty is not technical, and the premium you would pay for a forward deployed engineer buys you nothing extra.

Signals you actually do

1. The requirement is vague and spans several systems you already run. Not “we want an AI chatbot” but “complaints take too long, and the process is scattered across a ticketing system, call notes and a chat group”. No product covers that off the shelf. Somebody has to define the problem first.
2. You have tried once. The demo worked; nothing reached production. More than 60% of enterprise AI attempts remain stuck in pilot. That is the norm, not a verdict on your team. The blockers are usually integration, permissions, data quality or the absence of anyone pushing — not the model.
3. There is a gap between the business and the technical team. The business cannot say what it wants; engineering cannot hear what the business is saying. The time split of the role is telling: customer communication 47%, writing code 31%, internal coordination 22% (Perspective AI, survey of 1,500 practitioners). More than half of the job is not code.
4. There is a specific business metric to move. Cycle time on a document type, rework rate at one step of the process — not “we would like to try AI”. Without a metric there is no acceptance.
5. Nobody internally can work on it full time. People are willing to help, but they have a day job. Without steady business input, any delivery team slips.
6. You need somebody who will tell you the project is not worth doing. Most vendors will only ever say it is possible. Note how the role is built: 83% of FDEs do not report to sales, and none carry a sales quota — precisely so the judgement is not contaminated by the pressure to close.

Seven questions to settle in one meeting

Ask them internally. What matters is which ones you cannot answer.

1. Which metric are we moving, and where does it stand today? No answer → you have a wish, not a requirement.

2. Whose working day changes when this ships, and do they know? No answer → resistance will appear after launch, not during the build. The system ships and nobody uses it.

3. Which data, from which systems, and who can authorise access? No answer → the project stalls at interfaces and permissions.

4. If we ship a small version for one department only, is that a success? No answer → what you actually want is a platform, and scope brings cost and risk with it.

5. Who signs acceptance, and is the bar a number or a feeling? No answer → acceptance becomes an argument. The common failure is not build failure; it is a system nobody will sign off.

6. Who can commit fixed time every week? No answer → this is the one question that stalls every provider equally. No delivery team replaces your business input.

7. If validation says this is not worth doing, can we stop? No answer → you will buy a system nobody uses, and nobody will dare say so.

How to read the result: if you cannot answer 1, 3 or 5, definition is your gap — that is the work a forward deployed engineer does. If you cannot answer 2, 4 or 7, the gap is internal alignment, and a meeting is cheaper than a vendor. If you cannot answer 6, fix the staffing before you discuss solutions.

Three alternatives, compared honestly

Path	Fits when	Cost structure	Main risk
Buy a product / SaaS	The requirement is standard and a product covers most of it	Subscription or per-seat, predictable	You adapt your process to the remainder; data leaving your environment adds compliance work
Hire and build in-house	You intend to do this for years, and have someone who can direct it	Hiring time plus salary. In China the average FDE salary is RMB 408,000, median 366,000; postings on Maimai rose 21× year on year in H1 2026, 37.3% of them from AI-native companies — you are bidding against those companies for the same people	You cannot hire; the first project is tuition; if the work stops, the people stay
Traditional outsourcing / staff augmentation	The requirement is clear and stable, and what you need is execution	Priced per person-day or person-month, scaling linearly	Nothing compounds: the next similar project costs the same again

To be direct: often one of these three is the better call. If a product covers most of the requirement, buy it. If you can make the directional calls and only lack hands, hire. If the specification is already written, buy capacity by the day — the boundary between the two models is set out in FDE vs outsourcing. Forward deployed engineering is the right answer only when the missing piece is definition.

The accounts worth running

We do not publish prices — the same scenario costs very different amounts in different companies. Which accounts to run, though, is general:

• Pilot spend. Not the budget for the whole project, but the minimum needed to test whether the approach works at all. Keep it as its own line, and accept that it may return nothing.
• Your own people’s time. Business, IT, data and legal, each for how many hours. This rarely appears in a project budget, yet it is a real cost — and the most common cause of delay.
• The hidden cost of data preparation. Where the data is, how good it is, how access is granted, whether it may leave your environment. Often slower than the modelling itself.
• The cost of time lost. Not what was spent, but how far the project slipped and how much patience the business burned while waiting.
• The cost of the second one. When a similar use case comes up again, do you buy it all over again? The test: if the first client takes ten person-months and the tenth client in the same industry still takes ten, the model has not worked (Bob McGrew, formerly of Palantir). In buyer’s language: are you paying for method, or only for time?
• A red line in reverse. If one customer — you — permanently absorbs a provider’s delivery capacity (a single client above 30–40%, per F-Prime), that provider is high-end staff augmentation and is unlikely to compound anything for you.

A worked example

This is an illustrative walk-through of the method. It is not a customer case, and it describes no real company.

A manufacturer wants AI to handle quality inspection reports. Inspectors fill in forms daily, reports are compiled by hand, and tracing a customer complaint means digging through records.

Run the questions. Management says the goal is fewer missed defects, but nobody has ever counted missed defects; the only record is complaints. Question 1 comes back incomplete. The data sits in equipment exports, a shared drive of old reports and a separate ticketing system, with no common identifier — that is “spans several systems you already run”. The inspection supervisor is willing to help but also runs the line, so question 6 has no answer.

Check the alternatives. Inspection-vision products decide pass or fail from an image; they do not turn that decision into a report that is filed and traceable. Hiring in-house is not on the table for a capability the company does not intend to keep. Outsourcing needs a specification nobody can write yet.

Run the accounts. Keep the pilot as small as possible: one report type, one line, one measurable metric. The internal cost is the supervisor’s fixed weekly time, and scheduling has to avoid peak season. The data-preparation cost sits mostly in the inconsistent formats of historical reports.

The conclusion here is that this looks like a definition problem, which is where a forward deployed role earns its place. The conclusion is not “hire an FDE”. It may equally be “spend a few weeks defining the metric and the identifier scheme, then decide whether to spend anything”.

FAQ

How big does the budget need to be to make this worth doing? We do not quote figures. A workable method: cost the smallest version that could validate the idea, including your own people’s time. If that exceeds what the project could plausibly return within a year, do not do it. And if you can afford manpower but not the diagnosis and pilot that precede it, you are buying outsourcing — so buy it as outsourcing.

Can we do this without data? Most companies are not short of data; they have data that is scattered, inconsistently formatted and unauthorised. The one genuine blocker is a process that was never recorded at all and lives in people’s heads. There, the first step is not AI; it is writing the process down.

Can we start with a small part of it? Yes, and you should. Smaller scope means faster acceptance and cheaper failure. The risk is cutting so small that nothing of business value can be shown. The test is simple: once that piece is live, does anybody use it every day?

What if internal opposition is loud? Separate the sources. If the fear is replacement, say plainly how each person’s work will change. If the fear is carrying blame, put acceptance criteria up front and accept that a failed validation stops the work. If the objection is “this will never work”, answer it with the smallest possible validation rather than with a slide deck.

---

Forward deployed engineering is not essential equipment. It is one answer to one class of problem. Our own test for taking a project is simple: if your people can write the specification, we will tell you that you do not need us.

For the background, read What is a forward deployed engineer?. For the procurement traps, see FDE vs outsourcing. If you already have a specific scenario, look at how our FDE outsourcing service delivers, or talk to us for an assessment.