The Forward Deployed Engineer Lifecycle (FDE Lifecycle): From Problem to Production

The forward deployed engineer lifecycle is the arc of a single customer engagement: you scope a problem with the customer, map how the work actually happens, build a prototype against their real data, harden it into something production-grade, deploy it inside their environment, and hand it over to the people who will own it after you leave. Typically weeks to a few months, not days. The stage names vary by company, but the underlying sequence is what stays stable.

The role itself is growing fast. AWS announced a $1 billion investment in June 2026 to build a dedicated Forward Deployed Engineering organisation, embedding engineers directly inside customer teams. Wikipedia’s entry on the Forward Deployed Engineer notes the term was popularised by Palantir and that companies including AWS, OpenAI and Anthropic have hired for it, with listings growing significantly between 2024 and 2025.

---

The Seven Stages of an FDE Engagement

This table is the page. Every stage gets an exit criterion (what has to be true before it ends) and a characteristic failure (how it usually goes wrong).

Stage	What Actually Happens	Exit Criteria	How It Usually Fails
1. Qualification and scoping	Deciding whether this is a problem worth deploying against, and writing down what success would look like	A named business owner has agreed in writing what “better” means and how it will be measured	Scoping to a problem the customer cannot get data for, or defining success so loosely that anything counts
2. Discovery	Learning how the work actually happens today: the real workflow, the real data, the people who will use it	You can describe the current workflow back to an operator and they confirm it is accurate	Discovery that only ever spoke to managers, never the people who will actually use the system
3. Prototype	A working thing on the customer’s real data, built fast, deliberately not production-grade	It runs on the customer’s actual data, not an extract you were emailed	A prototype quietly promoted to production because it demoed well in a meeting
4. Pilot / proof of value	Real users, real workload, a bounded scope, and a measurement of whether it helped	A real user has completed a real task without you in the room	A pilot with no named owner on the customer side, so nobody can say whether it worked
5. Hardening	Turning the prototype into something that survives contact with production: errors, scale, security, evaluation, monitoring	It handles failure gracefully, has evaluation baselines, and someone besides you understands how it works	Skipping this stage entirely and calling the prototype “done” because the demo went well
6. Production deployment	Running inside the customer’s environment, integrated with their systems, with alerting and an owner	It is running in the customer’s environment with monitoring, alerting and a named person who gets paged	Deploying without monitoring, so nobody knows when it breaks until a user complains
7. Handover	Transferring ownership to people who will keep it running, and feeding what was learned back into the product	Someone who is not you has fixed something in it and it worked	Handover to a team that was never in the room during the engagement

Stage names and counts vary by company. Some organisations merge prototype and pilot. Others split deployment from adoption. The sequence is what stays stable.

If you are comparing what employers actually require to do this work, the FDE job description analysis breaks down what real postings at Anthropic, OpenAI and Palantir contain.

The late stages are where most engineers find the gap: hardening a prototype into something that survives production inside someone else’s environment. The Advanced Certificate in AI Forward Deployed Engineering with IIT Delhi is built around exactly that half of the lifecycle: RAG architecture, agentic systems, LLM evaluation and observability, cost and latency at scale, security, and production deployment.

---

How Long Does Each Stage Take?

Three published frameworks give different numbers. All three are attributed; none should be treated as an industry standard.

Rocketlane’s blueprint (21 May 2026): qualify and scope 1-2 weeks, discovery and architecture 2-4 weeks, build 4-12 weeks, deploy and measure 4-8 weeks.

Perspective AI’s playbook (12 Jun 2026): discovery weeks 1-4, prototype weeks 3-6, deploy weeks 6-10, productise days 60-90, hand off days 90-120.

Umbrex’s playbook (modified 11 Aug 2026): places production deployment, adoption and operational handoff at roughly weeks 7-12 of the engagement.

The observation worth making: Perspective AI’s phases overlap deliberately. Prototype starts in week 3 while discovery is still running to week 4. Discovery does not finish before building starts; it finishes because building started and taught you what you had missed. That is the most useful single thing on this page for someone about to do the job.

Contract and product drive the variation more than any framework does. A 30-hour integration engagement has a different shape from a six-month enterprise deployment. Use these numbers as a sense of scale, not as a plan.

What Changes About Your Job at Each Stage

Early: You Are Mostly Listening

Scoping and discovery are interview work. The output is a written, agreed problem statement, and the skill is asking the question that reveals the workflow nobody documented. Very little code in this phase. Engineers new to the role find this stage the most uncomfortable, and it is where engagements are actually won or lost. A problem scoped to something the customer cannot measure is an engagement that will end with nobody able to say whether it worked.

Middle: You Are Building Fast and Throwing Work Away

Prototype and pilot reward speed over structure, and a lot of what you build here is meant to be discarded. The discipline is knowing which parts are experiments and which are becoming load-bearing. A prototype that only ever ran on a sample extract, never on the customer’s live data, will fail the moment someone tries to use it for real. Build on the real data from the start.

Late: You Are an Engineer Again, with Someone Else’s Constraints

Hardening, deployment and handover are production engineering inside the customer’s security review, network policy and change process. This is where the work most resembles ordinary software engineering, and where the customer’s environment makes it harder than it would be at home. You are writing the same kind of code you wrote before, but inside constraints you did not choose and cannot change.

The lifecycle asks for three different working styles in sequence, and most people are naturally strong at one of them. Naming which one you are is more useful than pretending to be equally good at all three.

What “Done” Actually Means

The naive answer is wrong. An engagement is not done when the system is live. It is done when the customer can keep it running without you.

Handover is a stage, not an email. Umbrex devotes a whole chapter to handoff rules between the forward deployed engineer, implementation, support and customer success. The reason is that this is where engagements silently fail. The system runs, nobody owns it, and three months later someone asks “who maintains this?” and nobody knows.

The compounding argument. Perspective AI makes the point that a clean handoff is what lets a small FDE function “compound instead of getting trapped maintaining everything it ever built.” Every deployment you still personally own is capacity you no longer have for the next engagement. The FDE who hands over cleanly ships again next month. The one who does not becomes a maintenance engineer for their own past work.

The feedback loop closes the lifecycle. What you learned at the customer goes back into the product. The diginomica account of how IFS connects FDEs into the product lifecycle describes a model where the product team is engaged through implementation for exactly this reason. IFS’s Chief Product and Customer Officer Cathie Hall warned (diginomica, 5 Jun 2026): “Sending an engineer in isolation can develop a solution, but is that solution really enterprise-grade? Is it really supportable? Is it really operable? Can we really roll it out globally?” The answer is that the feedback loop between the field and the product team is what makes it enterprise-grade.

The test you can apply: has anyone who is not you changed something in this system and had it work? Until that is true, it has not been handed over.

Do all companies run the same FDE lifecycle?

No. Stage names and counts differ. Some merge prototype and pilot. Others split deployment from adoption. The sequence, understand the problem, build small, prove it works, harden it, deploy it, hand it over, is what stays stable.

The late stages are where most engineers find the gap: hardening a prototype into something that survives production inside someone else’s environment, with evaluation and monitoring on it. The Advanced Certificate in AI Forward Deployed Engineering with IIT Delhi is built around that half of the lifecycle: RAG architecture, agentic systems, LLM evaluation and observability, cost and latency at scale, security, and production deployment on Bedrock, Azure OpenAI or Vertex, across six months of live online sessions with recordings and five projects.

---

Frequently Asked Questions