When forward deployed engineering is the wrong answer

We sell this model, so treat this page as the one we have the least incentive to write. It is here because a hub that only argues for the thing it sells is not worth citing.

Forward deployed engineering costs real money. An engineer assigned to one customer is an engineer not building the product, and the cost reduces gross margin, which everyone can see. That price is worth paying under specific conditions. Here is when it is not.

Disqualifier one: the contract cannot pay for the engineer

Work out what one engineer costs you loaded for a quarter, then compare it with the annual value of the account. If the deployment cost is a large fraction of the contract, the model consumes the revenue it produces.

First Round Review's February 2026 guidance cites Looker validating $25,000 or more in annual contract value, along with a trajectory toward 2,000 customers and $100 million in recurring revenue, before it committed to the model. Do not adopt that number: your costs and margins are different. Do the same calculation for your own business, and write the minimum down before the first engagement, because working it out afterwards is how companies discover they have built a services business by accident.

Instead: self-service onboarding, a template implementation, a partner network, or a documented integration path. First Round's own framing is to complement embedded work with repeatable implementations for smaller accounts and reserve engineers for the highest-value ones.

Disqualifier two: your customers all want the same thing

The model is worth its cost when environments differ from each other. If every customer's integration is the same, an embedded engineer is an expensive way to click through a setup screen.

The test is concrete: look at your last five implementations and count what was genuinely different in each. If the answer is a connection string and a logo, you have a documentation problem rather than a deployment problem.

Instead: invest in the implementation template, the connectors, and the setup documentation. That is a one-time cost that serves every future customer, which is the opposite of how the embedded model's cost grows.

Disqualifier three: you have a fixed product opinion

This is the one companies get wrong most often, because it feels like strength.

First Round Review puts it directly: if you hold strong opinions about product direction and do not want them changed, embedded engineers are a bad fit. The reason is structural. The value of putting an engineer inside a customer's environment is what they learn there, and that learning is only worth the cost if it can change what you build. A company that will not change its roadmap has paid for discovery it intends to ignore.

There is a worse version. Embedded engineers who report into sales, with no route for their findings to reach the product, generate customer-specific work that never generalises. Marty Cagan's September 2025 piece on the role warns that a separate professional services unit stops what engineers learn from reaching the product, and moves the company toward a pure services business. Where the function should report covers the fix.

Instead: if the product direction is settled, buy delivery rather than discovery. A systems integrator or a scoped build engagement will implement a known design for less.

Disqualifier four: you can already write the specification

If you can describe what needs building in enough detail that a competent team could deliver it without you present, you do not need discovery inside the environment. You need execution.

This is the most common case by volume and the easiest to misdiagnose, because "we need engineers embedded with us" and "we need more senior engineers" sound similar in a meeting.

Instead: staff augmentation if you have the technical leadership and need senior engineers under your direction, or a full product build if you want the whole thing owned to a specification. FDE versus staff augmentation is the page that separates those two properly.

The disqualifier that appears after you start

The four above are decidable in advance. This one is not, and it is the most damaging.

An engagement with no end date has stopped being a deployment and become a dependency. The signs are recognisable: the production date has moved twice, the customer's own engineers have not touched the system, the scope grows by one reasonable request a week, and both sides have started calling it a partnership.

That arrangement can be profitable for a vendor and it is bad for the customer, so the safeguard has to be structural rather than cultural. When AWS announced its own forward deployed engineering organization in June 2026, it named customer self-sufficiency after the engagement as a design goal. Require that of every vendor, and of us: a production date and a handover date, named in the contract at signature.

Handover and exit covers how to design the ending, and what goes wrong lists the rest of the failure modes with their warning signs.

The honest summary

Two or more of the four disqualifiers means do not use this model. One means proceed and write down how you will manage it. None means the model probably fits, and the remaining question is whether you build the function or buy it, which is three routes with different costs.

And if you are unsure, the cheapest next step is not a pilot engagement. It is looking at your last five implementations and counting what was actually different about each one. The executive briefing is the one-page version of that decision for whoever approves it.