Forward deployed engineer ROI: a working model

Short version: an AI project does not pay back through headcount saved alone. Four accounts have to be run — direct cost, hidden cost, risk cost and reuse benefit. Run only the first and almost everything looks profitable. Run all four and roughly half the pipeline disappears. That is the point of running them.

Account one: direct cost

Build and delivery effort, compute, licences. Watch the pricing unit too — per person-day, per stage or per outcome — because it decides who carries the risk. The usual error is counting only what it costs to make the thing.

Account two: hidden cost

• Data preparation. Finding the data, cleaning it, labelling it, getting access to it. On most projects this takes longer than the modelling.
• Your own people’s time. Business, IT, data and legal. It rarely appears in a project budget, it is always a real cost, and it is the most common cause of slippage.
• Process change. If the process cannot change, the system gets worked around.
• Training. If nobody uses it after go-live, nothing was delivered.

For scale, look at how the role itself spends its time: customer communication 47%, writing code 31%, internal coordination 22% (Perspective AI, survey of 1,500 practitioners). More than half of the supplier’s hours are not code. Your organisation absorbs a comparable load of coordination, and none of it arrives on an invoice.

Account three: risk cost

Failure probability × spend sunk. More than 60% of enterprise AI attempts remain stuck in pilot. That is not a prediction about your project. It means “success by default” is not a safe assumption, so the model needs a line for failure.

Method: cost the smallest version that could validate the idea, then apply your own historic hit rate. If the project has stage gates — stop if validation fails — the downside has a ceiling. If it does not, the risk line is unbounded, and that is the quiet reason large AI programmes fail expensively.

Account four: reuse benefit

This account is the cost of the second, similar use case. 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). Where that holds, your second and third scenarios cost the same as the first, and any multi-scenario business case is systematically overstated.

The reverse red line: when a single client permanently absorbs 30–40% of a supplier’s delivery capacity, the business has become high-end staff augmentation (F-Prime). Set reuse benefit to zero.

The cost most contracts leave out

“Deployment is about 20% of the cost; the other 80% is keeping the system working through model upgrades, data drift and edge cases” (John Sangyeob Kim of Solidroad, reported in Computerworld; the reference period is 18 months). Most agreements price only the first part.

Two consequences for the arithmetic. Put running cost into the denominator as a continuing line, or the payback period you present will be shorter than the real one. And ask for a cost formula at handover rather than a running-cost quote — a formula survives a change of volume, a quote does not.

Metrics that belong, and metrics that mislead

Process metrics are call volume, accuracy, latency, coverage. Business metrics are cost down, throughput up, revenue up.

The practitioner’s summary is exact: accuracy and latency are intermediate metrics; cost reduction, throughput and revenue are the objective. The reverse also holds: a million API calls in the CTO’s quarterly review may be a million pointless follow-up questions to the CEO.

Two conversions are worth doing. Accuracy only means something once it is multiplied by the manual review rate and the cost of an error; call volume only becomes work done once it is divided by calls per task. The test is simple: if a metric can improve without changing anybody’s working day or any line of spend, it is a process metric and does not belong in the numerator.

A worked example

Illustrative arithmetic, not a customer case. The figures are assumed, to show the method.

Suppose one item takes 12 minutes of human handling. With the system it takes 4 minutes of processing and 2 minutes of human review — 6 minutes in total. Volume is 200 items a day.

• Time saved per day: (12 − 6) × 200 = 1,200 minutes = 20 hours
• Per month, at 21 working days: about 420 hours
• Convert with your own fully loaded hourly cost C, not the salary line. (As an anchor for engineering cost in China: average FDE salary RMB 408,000, median RMB 366,000, per Liepin. Substitute your own number.)
• One-off cost: pilot and delivery (account one), plus data preparation and internal time (account two)
• Running cost: the monthly line from the 20/80 split
• Payback = one-off cost ÷ (monthly saving − monthly running cost). If that denominator is zero or negative, no accuracy figure rescues the case
• Risk: multiply by (1 − failure probability), or at minimum cost the total-loss scenario
• Reuse: if a second similar scenario costs materially less, add the saving for each additional scenario

Two places this goes wrong. The 2 minutes of review is the line people leave out: drop it and the saving looks like 67% when it is 50%. And volume does the heavy lifting. At 200 items a day the case stands; at five items a day, the same efficiency gain never repays a one-off build.

One table is enough for the decision: one-off cost, monthly running cost, monthly saving, the cost if it fails, and the reuse assumption. If those five cells cannot be filled, the calculation is unfinished — which is not the same as the project being a bad idea.

When the numbers do not work

1. There is no baseline. If average handling time or rework rate has never been recorded, the numerator cannot be calculated and acceptance becomes a matter of opinion. Two weeks spent measuring the baseline is cheaper than starting with the model.
2. Volume is too low. Run the arithmetic above and the one-off cost never amortises.
3. The process is not stable enough to automate. AI amplifies a process: exceptions that live in people’s heads become branches in a system.
4. A product already covers it. Buy the product.
5. Nobody owns the running cost. 80% of the cost sits after go-live. Without a named maintainer, the system fails quietly within months.
6. There is no way to stop. With no gate that ends the work on a failed validation, the risk line grows without limit — not because you will certainly fail, but because you cannot stop when you do.

FAQ

Is headcount saved enough to justify this? No. Headcount is part of the first account only. A complete case also weighs hidden cost, failure probability and reuse benefit. Cases built on headcount alone tend to fall over at the second and third scenario.

How quickly should it pay back? We do not quote figures; the method matters more than the number. Cost the smallest version that could validate the idea, then ask whether it can be covered by benefits you can actually confirm within a year. If it cannot, or if the denominator (monthly saving − monthly running cost) is zero or negative, do not proceed.

Is a failed pilot a total loss? Not always — but do not use that to dress up a loss. Evaluation sets, data standards and connectors can survive the project. The only test is whether a similar scenario costs less next time. If all that remains is a slide deck, the loss was total.

---

The purpose of the calculation is not to produce a number that gets the project approved. It is to answer, before the money is spent, whether the case holds. Our own habit is to start with the denominator: when running cost cannot be estimated, we do not proceed.

If it is still unclear whether your problem is one of definition or one of execution, read What is a forward deployed engineer? and FDE vs outsourcing. When the numbers are done and delivery is the next question, see how we deliver and our FDE outsourcing service. If you have a specific scenario, talk to us for an assessment.