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 keeps moving later.

The warning sign. 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.

What it looks like from inside. Six months into an engagement, everyone involved would say it is going well. The vendor's engineer is trusted, responsive, and clearly good at the job. The system does more than it did at the start. Nobody would describe this as a problem in a status meeting, because nothing about it feels like a problem in a status meeting. The only way to see it is to ask a question the status meeting never asks: if this person left tomorrow, who on our side could keep this running. When the honest answer is nobody, the engagement has quietly become permanent, regardless of what the contract says.

Two: the demo that never becomes ready for production

What it is. An impressive prototype that cannot keep working in production, usually because the rest of the system came to depend on its shortcuts.

The warning sign. 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 releases in week one covers the discipline.

A common version. Week one, the engineer connects directly to a production database because setting up a proper read replica would take three days they do not have, and the demo works. Week six, three other features have been built on top of that same connection because it was already there and worked. Week twelve, someone asks why the system cannot handle the customer's real data volume, and the answer is that the direct connection was never meant to survive contact with real load. Rebuilding the data access layer now means touching four features instead of one, which is the exact cost the written note in week one would have made visible before it compounded.

Three: the engineer who became an account manager

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

The warning sign. The time split has moved away 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 asking again and again for 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 a person on the customer side who removes obstacles, so neither job goes to the builder.

How to tell the three causes apart. Look at the calendar rather than the complaint. If most meetings are the engineer asking clarifying questions about what to build, the scope was never set and someone needs to set it. If most meetings are the engineer chasing a signature, an approval, or an account, the customer's organization is the obstacle and needs a named person to clear it. If most meetings involve the customer's business stakeholders rather than its engineers, and there was never much code being written to begin with, the role was presales from the start and calling it something else earlier would have saved both sides a difficult conversation later.

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 warning sign. 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 but no reusable work builds up.

The intervention. A regular productization process 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 signs look like success. Contracts are signed and customers are delighted, because each got software built exactly for them. The cost appears two years later.

Five: the pilot that was never going to production

What it is. A pilot runs, works, impresses people, and stops. Nobody cancelled it and nobody released it.

The warning sign, 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 across many companies.

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.

Why this one is so common. A pilot needs a smaller decision than a production rollout. It usually needs one manager's sign-off rather than a change advisory board, a security review and a budget committee, so it gets approved quickly and the production step gets skipped over in the excitement of a working demo. The fix is to require the same three answers, a named owner, a budget line, and a stated path to production, at the moment the pilot itself is approved, rather than waiting until the pilot succeeds and discovering that nobody thought about what happens next.

Six: the handover that was a slide deck

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

The warning sign. 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 releases 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 warning signs rather than the status report, because every one of these failure modes can exist alongside a status report that says everything is fine 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.

None of these six require a difficult vendor or a difficult customer to occur. Every example above involves reasonable people making reasonable decisions in the moment: skip the read replica this week, let the pilot's manager approve it alone, let the demo become the plan since it is working. The failures accumulate from small, sensible choices rather than from anyone acting in bad faith, which is exactly why checking a status report is not enough. A status report asks whether things are going well this week. These six questions ask whether the structure underneath is quietly building a different outcome than the one anyone intended.