What goes wrong in forward deployed engagements

These are the ways embedded engagements fail. Each one is recoverable when named early and expensive when discovered late.

One: the endless engagement

What it is. The engagement has no end. Scope grows by one reasonable request a week and the production date recedes.

The tell. The production date has moved twice. The customer's own engineers have not touched the system. Both sides have started calling it a partnership rather than a deployment.

Why it happens. It is comfortable. The vendor has predictable revenue and a happy customer; the customer has capable people handling something they never staffed. Nobody is behaving badly, and the outcome is still a dependency.

The intervention. A handover date in writing, and a named inheriting engineer. Structural rather than cultural, because goodwill does not produce endings. Handover and exit covers it.

Two: the demo that never hardens

What it is. An impressive prototype that cannot survive production, usually because its shortcuts became load-bearing.

The tell. The demo gets better every month and the production date does not get closer. Nobody can say what the prototype fakes.

Why it happens. Week-one shortcuts are correct decisions: hardcode the credential, skip the pagination, query production directly. Then somebody senior sees the demo, the demo becomes the plan, and the shortcuts are in the critical path.

The intervention. Write down what the prototype fakes, in the same week you build it. Keep it small enough to discard. What a forward deployed engineer ships in week one covers the discipline.

Three: the engineer who became an account manager

What it is. The embedded engineer's week fills with meetings, status updates and chasing approvals, and the building stops.

The tell. The time split has drifted from the roughly 20 percent customer-facing and 80 percent building that First Round Review describes, toward half and half or worse.

Why it happens. Three causes, and it is worth knowing which. The scope is unclear so the engineer is establishing it in meetings. The customer's organization is blocking and the engineer became the person chasing signatures. Or the role was presales all along and nobody said so, which the three jobs page shows is 30 percent of the market.

The intervention. Name an account owner on the vendor side and an unblocker on the customer side, so neither job lands on the builder.

Four: the bespoke fork nobody can upgrade

What it is. The deployment is its own codebase. It works, and it cannot take a platform upgrade without a project.

The tell. Nobody can say where shared product ends and custom code begins. The custom share grows with each account rather than shrinking.

Why it happens. No reusable platform underneath, and no owner for generalising. a16z's Marc Andrusko describes the end state as a large number of bespoke deployments that are impossible to maintain or upgrade, where revenue grows and nothing compounds.

The intervention. A productization cadence with a named owner, and a tracked ratio of shared to custom code per account. The productization loop and revenue per engineer are the mechanisms.

Why it is the worst one. The early signals look like success. Contracts close and customers are delighted, because each got software built exactly for them. The bill arrives two years later.

Five: the pilot that was never going to production

What it is. A pilot runs, works, impresses people, and stops. Nobody killed it and nobody shipped it.

The tell, available on day one. There is no named production owner, no budget line beyond the pilot, and no answer to what has to be true for this to reach production.

Why it happens. Pilots are easy to fund and production is hard to fund, so a pilot becomes the thing that gets approved. MIT NANDA's July 2025 study reported that 95 percent of generative AI pilots delivered no measurable profit-and-loss impact, drawing on 52 executive interviews, 153 leader surveys and 300 public deployments. That number describes this failure at scale.

The intervention. Ask the three questions before starting. If any answer is missing, the honest move is to fix that first, because a pilot with no route to production is a demo with a budget.

Six: the handover that was a slide deck

What it is. The vendor left, documents were delivered, and the system came back as an emergency within a quarter.

The tell. No engineer on the customer's side has ever changed the system alone. The handover artefact contains no runnable tests.

Why it happens. Handover gets treated as a documentation task at the end rather than a capability transfer that starts at production.

The intervention. The customer's engineer ships a real change unaided, through the real release path, before the vendor leaves, and the vendor watches rather than helps. Schedule it a few weeks before the handover date so there is time to fix what it exposes.

How to use this list

Read it at week three and again at the halfway point. Check the tells rather than the status report, because every one of these failure modes coexists with a green status report for a while.

And notice what the interventions have in common: a name and a date. Almost every failure here is somebody's job that nobody was assigned.