Pricing an FDE engagement: time-box, milestones, exit

Forward deployed engineering has a pricing problem that nobody puts in the pitch deck.

When it works, an engineer sits inside a client for some weeks, turns a stalled AI pilot into a running system and then leaves. When it does not work, the same engineer is still sitting there eighteen months later, the "pilot" has become a dependency, and the client is paying a services bill for something that never learnt to stand on its own.

Both outcomes start with the same statement of work. The difference is how the engagement was priced and how it was bounded.

The money going into this model makes it urgent. AWS has committed $1 billion to a forward deployed engineering organisation, OpenAI's deployment business launched with more than $4 billion, and US FDE postings passed 7,300 in the first nine months of 2026, per Lightcast data reported by CNBC. One October census of 1,465 postings put the median posted base salary at $200,000, among the 849 postings that quote a verified pay in US dollars (topfdejobs). Senior field engineers are expensive. Every week they spend on the wrong problem is expensive.

I am writing this from the side I sit on. I am an independent architect, I contract through my company Aurelia Innovatives, and I work with enterprises and services firms in India and outside.

Scaffolding, not the house

The best framing I have read on this is a16z's "The Palantirization of everything". It says forward deployment is scaffolding, not the house. Embedding engineers to get the first customers into production is correct, but only with explicit constraints, like a time-boxed "90-day sprint to production" and a clear ratio of engineering headcount to revenue on an account.

That essay is written for software vendors. The same logic applies when an enterprise buys FDE time from a partner. The scaffolding has to come down at some point. If the pricing does not say when, nobody takes it down.

Three pricing models and what each one rewards

Time and materials. You pay for days. This rewards being present, not outcome. It suits discovery work that is genuinely unknown, and almost nothing else. On AI work it fails in a very specific way. The hardest part, getting data access and agreeing the evaluation, is slow and mostly waiting. T&M bills the waiting.

Fixed price for a deliverable. You pay for "an agent that does X". This rewards scoping X narrowly enough to hit it. It goes wrong when X gets defined before anyone has seen the data, which on AI work is nearly always the case. Then the fight is about whether the thing delivered is the thing promised.

Milestone based, time-boxed. You pay in tranches tied to gates, inside a fixed calendar window, with a written exit at each gate. This is what I use: one bounded use case, paid by milestone. It rewards getting to production, and it also rewards stopping honestly when you should stop.

The gates I price against

I tie payment to four gates. Amounts change per engagement. The structure does not.

Close

Four gates inside about 90 days, paid by gate. Gate 1 readiness, weeks 1 and 2, ends in proceed, reframe or pause. Gate 2 first slice, weeks 3 to 6, real data scored on the evaluation set. Gate 3 production, weeks 6 to 10, approvals, monitoring and a cost budget. Gate 4 handover, last two weeks, the owner runs it and we only watch. If gate 3 cannot be reached inside the time box, re-scope and do not extend.

1. Readiness, weeks 1 and 2. The workflow is written down. The data owner has granted access in writing. A business owner has agreed the evaluation set and the success threshold. Someone on the client side is named to run the system afterwards. The output is a recommendation: proceed, reframe or pause. I price this gate as a standalone review, so pausing costs the client two weeks, not a quarter.
2. First working slice, around weeks 3 to 6. The workflow runs end to end on real data in a non-production environment and gets scored against the evaluation set.
3. Production, around weeks 6 to 10. It runs for real users, behind the agreed approvals, with monitoring and a cost budget.
4. Handover, final two weeks. The named owner runs it while we watch. The runbook exists. Our access is reduced.

The whole thing sits inside roughly 90 days. If it can not reach gate 3 in that window, the engagement was mis-scoped, and the right move is re-scope, not extend.

The costs most proposals leave out

When I review other FDE proposals for clients, four cost lines are usually missing.

• Access lead time. Service accounts, VPN, data-sharing approvals and security review often take longer than the build itself. If the client's process takes four weeks, the price must assume four weeks. I wrote about running that negotiation in the data-access negotiation.
• Evaluation effort. Building and agreeing a test set with the business is real work for both sides. It belongs in the plan and in client resourcing, not hidden inside "build".
• Model and token costs. Agent loops make inference a visible line item. Estimate it from real samples and give a range, not one number.
• Client side time. The business owner, the data owner and the future system owner each need a few hours every week. If those hours are not committed, the engagement stalls no matter what you pay the FDE.

The exit clause is the product

The most important line in an FDE contract is the one that says how it ends. Mine say three things.

• What "handed over" means, in terms you can observe. The owner has run it without us for two weeks, and the runbook covers the known failure modes.
• Any extension needs a new, named use case. "Continued support" is not a use case.
• The readiness gate can end in "pause", and that counts as a successful outcome of the review.

That last clause makes some sales teams uncomfortable. It is also the reason clients trust the recommendation when it says "proceed".

Verne Field Notes, linked from the FDE Hub reading list, has a good endpoint test: it ends when another team can run what was built. If you can not write that sentence into the contract, you are not buying forward deployment. You are buying staff augmentation with a better title.

For services firms building an FDE practice

Many of the teams I train at services firms and GCCs in Bengaluru and Pune are being asked to sell "FDE" from next quarter. A few things I tell their leaders.

• Price the readiness review separately. It is the cheapest way to avoid a bad engagement, and the easiest first sale.
• Do not staff FDE pods like delivery teams. A pod is two or three senior engineers with direct client access. It is not a pyramid.
• Track what you reuse. If engagement five costs the same as engagement one, you are a consultancy. That is fine, but price it like one.
• Assess FDEs on shipped, handed over systems, not hours billed. Anthropic's new programme assesses engineers on their work before they earn the credential (Anthropic). The same principle works for internal promotion.

Limits

These are patterns from my own engagements, not industry benchmarks. Some work genuinely needs open-ended discovery, and some regulated environments can not move inside 90 days. In those cases I shorten the first box instead of lengthening the whole engagement.

Learn to run engagements this way

If you want your engineers to run engagements like this, the AIXL Academy Forward-Deployed AI Engineering cohort is where each participant ships one bounded use case and gets assessed on it. Dates and fees are on the AIXL Academy page. The method behind this is set out in forward-deployed engineering. If you want a readiness review on a pilot that is stuck, you can reach me through this site.

Common questions

How should a forward deployed engineering engagement be priced?

As a time-boxed sequence of milestones, usually readiness, first working slice, production and handover, with payment tied to each gate and a written exit at each one.

How long should an FDE engagement last?

For one bounded use case, about 90 days to production and handover is a useful default. If it can not reach production in that window, re-scope instead of extending.

What costs do FDE proposals usually miss?

Access and security review lead time, evaluation effort, model and token costs, and the weekly hours of the business, data and system owners on the client side.

What is the difference between FDE and staff augmentation?

An FDE engagement ends when a named client team can run the system without help. Staff augmentation has no such endpoint.