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 lands on gross margin where everyone can see it. That price is worth paying under specific conditions. Here is when it is not.

Disqualifier one: the contract cannot carry 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 floor down before the first engagement, because working it out afterwards is how companies discover they have built a services arm 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 earns its cost when environments differ from each other. If every customer's integration is the same shape, an embedded engineer is an expensive way to run a configuration wizard.

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 the embedded model's cost curve.

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 moved, 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 kills the feedback loop and drifts 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 in the room, 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 hands 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. Hold every vendor to that, and hold us to it: 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 tells.

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.