The forward deployed delivery model: from signed scope to go-live

Generated by Claude through GigAI 0.1.11.10 on 2026-10-12.

Concept: Forward deployed engineering experience · also covers Solutions engineering, Implementation · Step 1 of 34 in AI forward deployed engineer · version 1

On this page

A forward deployed engineer (FDE) is a software engineer embedded with a customer, responsible for making the product work on that customer's real data, systems and processes. The model trades some product-team leverage for speed and proximity: the engineer owns discovery, integration, custom build and go-live, then feeds what was learned back into the core product. This lesson lays out the engagement lifecycle, how scope is kept bounded, and why AI deployments favor the simplest design that meets the goal.

Read more

How it is done in practice

A team assigns one or two FDEs and an engagement lead per customer. In the first week they hold a kickoff, file every access and security request, and shadow the users whose work will change. They write a short solution document, agree the pilot criteria in writing, and then ship a thin end-to-end slice on real data within the first few weeks. A weekly status note goes to the sponsor, a shared channel handles daily questions, and an out-of-scope list absorbs new requests. After go-live the team writes runbooks, hands operation over, and files a field report that proposes which custom pieces should move into the product.

Technologies

SlackLinearJiraNotionGoogle DocsGitHubClaude APIPythonTypeScript

Diagram

flowchart LR
  A[Signed scope] --> B[Kickoff and access requests]
  B --> C[Discovery]
  C --> D[Solution design]
  D --> E[Build in thin slices]
  E --> F[Pilot against criteria]
  F -->|criteria met| G[Go-live]
  F -->|criteria missed| E
  G --> H[Handover and runbooks]
  H --> I[Field report to product team]
  I -.-> D
flowchart LR
  A[Signed scope] --> B[Kickoff and access requests]
  B --> C[Discovery]
  C --> D[Solution design]
  D --> E[Build in thin slices]
  E --> F[Pilot against criteria]
  F -->|criteria met| G[Go-live]
  F -->|criteria missed| E
  G --> H[Handover and runbooks]
  H --> I[Field report to product team]
  I -.-> D

Subtopics

What the forward deployed role is and where it sits

Definition and origin

The role was popularized by Palantir, where engineers were placed directly with customers to adapt a general platform to specific operational problems. It has since spread widely among AI companies, because model-based products rarely work out of the box on a customer's data and processes. An FDE writes production code, but the unit of success is a customer outcome, not a shipped feature. The engineer spends much of the week with customer users and operators, and the rest building integrations, data pipelines, prompts, evaluations and custom application surfaces.

How it differs from neighboring roles

A solutions engineer mostly works before the sale, demonstrating fit and answering technical questions. A professional services consultant configures and implements against a statement of work. A product engineer builds for many customers at once. The FDE overlaps all three but is distinguished by owning code in production for one customer and having direct influence on the product roadmap. Many companies pair the FDE with a deployment or engagement lead who owns the commercial relationship, so the engineer can concentrate on technical delivery.

The engagement lifecycle from signed scope to go-live

Phases

A typical engagement runs through six phases. Kickoff confirms the signed scope, stakeholders, success measures and access needs. Discovery maps the current workflow and the systems involved. Design produces a short solution document and an integration plan. Build delivers in thin vertical slices against real customer data as early as possible. Pilot runs the system with a limited user group against agreed criteria. Go-live widens the rollout, and handover transfers operation to the customer team or a support function, with runbooks, dashboards and an owner for each alert.

What usually blocks delivery

The critical path is rarely the code. It is access: credentials, network allowlisting, security review, data sharing agreements and a sandbox that resembles production. Experienced FDEs request these on day one and track them as explicit dependencies with named customer owners. They also establish a weekly cadence with a written status note that states what shipped, what is blocked and what decision is needed, so that slippage is visible long before the go-live date.

Shaping work so scope stays bounded

Rough, solved, bounded

Shape Up describes shaped work as having three properties. It is rough: the description leaves room for the builder to make detailed decisions, unlike a pixel-level wireframe. It is solved: the main elements and how they connect are thought through, so the open questions are details and not the core approach. It is bounded: it states what is out of scope and how much time the work is worth. Applied to customer delivery, each milestone is written as a shaped pitch instead of a list of requested features.

Handling new requests mid-engagement

Customers surface new needs as soon as they see working software. The default response is not yes or no but a placement decision: does it replace something inside the current boundary, go into a later phase, or become a product request? Keeping a visible out-of-scope list in the engagement document makes this routine. Fixing the time and letting scope vary protects the go-live date, which is usually the commitment the customer's sponsor cares about most.

Choosing the simplest AI design that meets the goal

Workflows before agents

Anthropic's guidance on building agents separates workflows, where LLM calls and tools follow predefined code paths, from agents, where the model directs its own steps and tool use. The recommendation is to start with the simplest solution, often a single well-instrumented LLM call with retrieval, and add complexity only when measurement shows it helps. Agentic designs trade latency and cost for flexibility. In a customer deployment the simpler design is also easier to explain in a security review, easier to evaluate and easier to hand over.

Feeding field work back into the product

From bespoke build to reusable capability

The economic risk of the model is that every engagement becomes a one-off services project. The countermeasure is a deliberate loop: custom code is written in a separable layer, repeated patterns across two or three customers are flagged, and the product team absorbs them as configuration, connectors or platform features. FDEs write short field reports that describe the customer problem, the workaround built and the generalization proposed. Companies that run the model well measure how much of each new deployment is assembled from existing parts.

Sources

Related lessons

Technical scoping, design docs and solution architecture for customer engagements