Why Does Everything a Forward Deployed Engineer Built Evaporate Every Time

The Problem

Companies selling AI into the enterprise now send people inside. A forward deployed engineer sits at the customer for weeks or months, bolts adapters onto legacy systems, extracts business rules that were never written down anywhere, and reshapes messy production data into something the product can eat. When it is done, the system works. And almost everything created along the way stays inside that customer’s walls.

It stays there for good reasons. There is an NDA, there are data residency rules, and above all the artifacts themselves are saturated with the customer’s schema and business logic. You cannot even carry out a screenshot. So what accumulates on the vendor side is human memory plus a few wiki pages written weeks later if anyone finds the time. Wiki pages rot.

The result shows up as a margin curve. The third deployment takes about as long as the first. Revenue grows and cost grows with it, so the ceiling on growth becomes the hiring rate. How expensive that is can be read off the comp bands: in market data compiled by Christian & Timbers, median total compensation is $385,000 for mid-level FDEs, $610,000 at staff level, and north of $1.2 million for principals at frontier labs. Those are the people redoing the same mapping work at customer three that they did at customer one.

Why Now

Demand blew out first. From the same data, FDE postings on Indeed went from 643 in April 2025 to 5,330 in April 2026, a 729% jump, with 224 open roles across 39 AI companies as of mid-2026. Salesforce has publicly committed to hiring 1,000 of them. Perspective AI’s analysis of roughly 1,000 English-language postings puts year-over-year growth above 1,000% and finds that more than 70% of postings explicitly ask for requirements discovery and translating ambiguous business problems. Already, 41% of AI engineers spend over 30% of their time customer-facing.

The largest companies bet capital on the same shape. AWS said on June 30 it is putting $1 billion into a dedicated FDE organization, after OpenAI and Anthropic set up joint ventures at $4 billion and $1.5 billion. The detail worth stealing is why Amazon built in-house instead of spinning out a separate entity: to keep the IP inside. If the biggest player structures its org specifically so deployment assets do not leak away, everyone without that leverage needs a tool that does the same job.

The technical preconditions also arrived. Software that runs inside the customer environment and exports only summaries, keeping data in and letting shape out, is no longer exotic in privacy engineering. A proposal that would have died in legal review a few years ago now lands inside the negotiable range.

flowchart LR
  A[Customer environment<br/>integrations, mappings, prompts] --> B[Observer<br/>records what got built and how]
  B --> C[De-identified extraction<br/>values stripped, structure kept]
  C --> D[Vendor deployment memory<br/>searchable pattern library]
  D --> E[Next deployment<br/>start from a skeleton, not a blank page]

How to Build It

Narrow to one artifact type. Data mapping specs are the best first target. The table that translates a customer’s schema into the shape the product expects gets rebuilt at every deployment, is startlingly similar within a vertical, and leaves a reusable skeleton once column names and values are removed.

The tool runs inside the customer environment, on-prem or in their VPC, and raw data never leaves. Exactly three things go out: the shape of the schema, the form of the transformation rules, and the class of attempts that failed. That last one is quietly the most valuable, because which mapping was tried and why it broke never makes it into any wiki.

On the vendor side, a searchable deployment memory accumulates. The engineer walking into the next engagement searches by vertical, source system, and field structure, and gets back the mapping skeletons from three prior deployments plus the landmines that were stepped on. Day one starts from a draft instead of a blank page.

Half the design lives in the contract. Master agreements usually contain a derivative-assets ownership clause that is never enforced, because nobody can see what actually left. This tool hands the customer an audit log of everything exported. That is the sales pitch. The customer sees, for the first time, what the vendor takes; the vendor takes, for the first time, only what it is entitled to. Price it per FDE seat or per deployment.

Success Criteria

First, the de-identification design has to survive customer legal review. If it does not, the tool never gets installed and nothing else matters. That makes the customer-visible audit log a precondition rather than a feature.

Second, deployment two has to be measurably faster. If it is not, this is another documentation tool, and FDEs already drown in those. The first target worth aiming at is cutting time-to-first-working-integration in half by the third deployment.

What is left is picking the vertical. Patterns only repeat if the domain is narrow. Insurance claims, hospital billing, logistics settlement are all plausible candidates, and which one has the most standardized schemas is something you learn by riding along on two real deployments, not by reasoning about it.