Forward deployed engineering: the complete guide / Buying the capability

Buying the capability

How to choose a forward deployed engineering partner

Judge a forward deployed engineering partner on five things, in this order: which of the three jobs their engineers actually do, whether they will put a production date and a handover date in writing, what proves the code correct, how they decline work that only serves one customer, and who is accountable by name. A vendor who will not name a handover date is selling a dependency. A vendor with no answer on declining customisation will say yes to everything, and everything they say yes to becomes something you maintain.

Key takeaways

First criterion: which of the three jobs their engineers do. Across 1,000 postings, 30 percent using this title were presales roles.
Second: both dates in writing. A vendor who will not name a handover date is selling a dependency, whatever the deck says.
Third: what proves the code correct, especially where a model wrote it. Generated code is not secure by default.
Fourth, and the sharpest: how do they systematically decline customisation requests. No answer means they say yes to everything.

Five criteria in priority order, and what a good answer sounds like.

One: which of the three jobs do their engineers do?

The analysis of 1,000 postings carrying this title found three different jobs: production engineers embedded with customers at 60 percent, sales engineers with implementation duties at 30 percent, and internal tools builders at 10 percent. A vendor saying they provide forward deployed engineers is making a claim compatible with all three.

Ask: what share of the week will these engineers spend writing code that gets merged in our repository? Are they compensated on our system going live or on this contract being signed?

A good answer is a number above 70 percent and a statement that pay is base plus equity with no bookings component. Across the postings analysed, none of the genuine forward deployed roles were quota-carrying.

A worrying answer reframes the question toward the value of customer engagement. The three jobs page covers why this matters most.

Two: will they name both dates?

A production date, meaning the defined system running for real users. And a handover date, meaning they stop operating it and your people take over.

Ask: what dates will go in the contract, and what is the handover artefact?

A good answer names both dates and describes the artefact as a runbook plus a runnable test suite, and ideally proposes the handover test: your engineer ships a real change unaided before they leave.

A worrying answer offers a production target and treats handover as something to discuss later. AWS named customer self-sufficiency after the engagement as a design goal of its own programme, so the standard exists publicly and a smaller vendor declining to match it has made a choice.

Three: what proves the code correct?

Most vendors in this market now use AI to write code. That is fine and it changes what you should ask about.

Ask: what share of delivered code is model-generated, and what proves it does what the specification said?

A good answer describes checks derived from the specification, written before the code exists, and graded by something other than the model that produced the code. Generated code is not secure by default, and in your production environment a wrong answer is your incident and your regulator.

A worrying answer is that senior engineers review every diff carefully. That is a claim about attention, and attention does not scale with generation volume. Eval-driven development is the method to listen for.

Four: how do they systematically decline customisation?

This is the sharpest question on the list, borrowed from a16z's Marc Andrusko, who poses it as an investor pressure test. It works better as a buyer question.

Ask: how do you decide which customer requests to build and which to decline?

A good answer describes a rule. First Round Review's version is to expand scope when the work creates repeatable value and stop when the iteration only serves one customer. A vendor with a rule has thought about the failure mode.

A worrying answer is that they are customer-led and build what customers need. That vendor will say yes to everything, your system will accumulate one-off code, and you will maintain it after they leave.

Five: who is accountable, by name?

Ask: if this does not reach production, who is answerable, and what clause says so?

A good answer names a person and points at a contract term.

A worrying answer describes a team, a process, or a governance structure. Andrusko's related pressure tests are worth asking too: where does shared product end and custom code begin, and what does year-three margin look like on mature customers. A vendor whose margin never improves on long-standing accounts is running a labour business, and your renewal price reflects that permanently.

What not to weight heavily

Case studies with named logos. Useful and weak evidence. You cannot see what was actually delivered, and the interesting engagements are usually the ones under NDA.

Certifications. AWS's partner programme requires ring-fenced credentialed teams that pass a defined production-engineering bar, which is meaningful. Most other badges are marketing. Ask what bar was passed and who set it. How the four public programmes describe themselves is the benchmark to hold a smaller vendor against.

Team size. A larger bench is not better for this. A small senior team on your account beats a large one where two people know your system.

Methodology names. A named framework tells you they have a deck. Ask what happens when the framework's step three turns out to be wrong.

The reference question worth asking

Ask for a reference where the engagement ended and the customer's team took the system over.

Every vendor has references from happy ongoing engagements. A reference from a completed handover is much rarer, and it is the one that proves the model rather than the relationship. If a vendor cannot produce one, ask how many of their engagements have ever concluded.

And on us

We would fail the case-study criterion: we have no client testimonials to show you, and inventing them is the fastest way for a consultancy to become untrustworthy. What we will do is put both dates in the contract, tell you what proves the code correct, and hand over an eval suite your team can run. The service is here, and the questions to ask us are the same ones we would ask.

Best for

Evaluating vendors for an embedded engagement
Preparing questions before a vendor call
Deciding which evaluation signals to discount

Avoid if

You have not yet decided between building, staffing and engaging

Verify before you commit

Ask what share of the week their engineers spend writing merged code, and how they are compensated
Require a production date and a handover date in the contract, with a defined artefact
Ask what proves model-generated code correct, and who grades it
Ask how they systematically decline customisation requests
Ask for a reference where the engagement ended and the customer took the system over

Common questions

What should you look for in a forward deployed engineering partner?

Five things in order: which of the three jobs their engineers actually do, whether they will put a production date and a handover date in writing, what proves the code correct, how they systematically decline customisation requests, and who is accountable by name with a contract clause behind it.

What is the single best question to ask a vendor?

How do you decide which customer requests to build and which to decline? A vendor with a rule has thought about the failure mode. A vendor who says they are customer-led and build what customers need will say yes to everything, and everything they say yes to becomes code you maintain after they leave.

What if a vendor will not name a handover date?

Treat it as the answer. AWS named customer self-sufficiency after the engagement as a design goal of its own programme, so the standard exists publicly. A vendor who offers a production target and defers handover to a later discussion is selling an open-ended arrangement whatever the deck says.

What should you ask about AI-generated code?

What share of delivered code is model-generated, and what proves it does what the specification said. A good answer describes checks derived from the specification before the code exists and graded independently of the model that wrote it. A worrying answer is that senior engineers review every diff, since attention does not scale with generation volume.

How much weight should case studies carry?

Less than most buyers give them. You cannot see what was actually delivered, and the most interesting engagements are usually under NDA. A far better request is a reference where the engagement ended and the customer's own team took the system over, which proves the model rather than the relationship.

Do vendor certifications mean anything?

Some do. AWS's partner programme requires ring-fenced credentialed teams that pass a defined production-engineering bar, which is a real signal. Most other badges are marketing. Ask what bar was passed and who set it, rather than counting logos.

References

How a build like this runs

CapacityEmbedded build teamOur tooling and workflow, running inside your codebase and your standups.

More in Buying the capability

When forward deployed engineering is the wrong answer

Forward deployed engineering is expensive and it is often the wrong tool. It does not fit when your contract values cannot carry an engineer's time, when every customer wants the same thing, when you hold a fixed product opinion you will not change, or when the scope is something you can already write down. Each of those has a cheaper alternative that works better. There is also one failure mode that disqualifies the model after you have already started: the engagement with no end date, which has stopped being a deployment and become a dependency.

Forward deployed engineering as a service

There are three ways to get this capability: build the function in-house, staff individual engineers through a partner, or engage a firm that takes the outcome. Building gives you the most control and takes a hiring cycle plus two or three engagements of learning. Staffing is fastest to a body in a seat and leaves the delivery risk with you. Engaging a firm moves the delivery risk across the table, which only helps if the contract names the production outcome rather than an hour count. Most companies should build eventually and cannot start there.

Questions to ask a forward deployed engineering vendor

Twelve questions, each with the answer you want and the answer that should worry you. Five of them come from a16z partner Marc Andrusko, who wrote them as pressure tests for investors evaluating companies using this model; they work at least as well from the buyer's side of the table. The most revealing question on the list is how the vendor systematically declines customisation requests, because a vendor with no answer will say yes to everything and you will maintain all of it.

How to prepare your team for an embedded engineer

Three things have to exist before an embedded engineer starts, and all three are yours to provide: access provisioned and tested, one named person who can unblock, and one person with the authority to decline scope. The third is the one everybody forgets, and its absence is why engagements sprawl. Beyond that, the difference between a fast engagement and a slow one is mostly about how much context you share and how completely you include the person. Nobody writes this page, and it decides more outcomes than the vendor's methodology does.

Security and access for embedded engineers

Letting an outside engineer into your systems is a real risk and it is manageable with four rules: least privilege by default, repository access scoped to the repositories the work touches, production access as a named exception with an audit trail and an end date, and revocation on the handover date rather than whenever somebody remembers. What changes when a model writes the code is that the review gate before production matters more, not less, because generated code is not secure by default.

Previous: Forward deployed engineering as a service Next: Questions to ask a forward deployed engineering vendor