Forward deployed engineering: the complete guide / Buying the capability
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.
Key takeaways
- Ask what share of the week their engineers spend writing merged code. Under 70 percent and you may be buying presales.
- Ask how they systematically decline customisation requests. No rule means they say yes to everything.
- Ask what year-three margin looks like on mature customers. Never improving means a labour business and a permanent renewal price.
- Ask for a reference where the engagement ended and the customer took the system over, which is much rarer than a happy ongoing reference.
Take this list into the call. The framing for each is what a good answer sounds like and what a bad one sounds like.
On what the engineers actually do
1. What share of a typical week will these engineers spend writing code that gets merged in our repository?
Want: a number above 70 percent. Across 1,000 postings, genuinely production-focused roles reported 70 to 90 percent coding time.
Worry: a reframe toward the value of stakeholder engagement, or a number in the 30s, which describes the sales engineering variant that made up 30 percent of postings using this title.
2. Are these engineers compensated on our system going live, or on this contract being signed?
Want: base plus equity, no bookings component. None of the genuine forward deployed roles in that dataset were quota-carrying.
Worry: any variable tied to signature.
3. Will the same people who scope this be the people who build it?
Want: yes, and the ones on the call get named.
Worry: a scoping team and a delivery team, which puts the seam where accountability goes missing.
On dates and endings
4. What production date will go in the contract?
Want: a date for the defined system running for real users.
Worry: a target, a phase-one date, or a pilot date presented as the answer.
5. What handover date will go in the contract, and what is the handover artefact?
Want: a date, plus a runbook and a runnable test suite. Better: they propose the test themselves, where your engineer ships a change unaided before they leave.
Worry: handover treated as a later discussion. AWS put customer self-sufficiency in writing as a design goal, so the standard is public.
6. Can you give us a reference where the engagement ended and the customer's team took the system over?
Want: one.
Worry: only references from ongoing engagements. Then ask how many of their engagements have ever concluded.
On the code
7. What share of delivered code is model-generated, and what proves it does what the specification said?
Want: checks derived from the specification, written before the code exists, graded by something other than the model that wrote the code. Generated code is not secure by default.
Worry: senior engineers review every diff carefully. That is a claim about attention, and attention does not scale with generation volume.
8. Who gets production access, and under what terms?
Want: named individuals, a stated reason, an audit trail, an end date. Default to none.
Worry: a request for broad access to make things easier. The contract page covers the terms.
The five pressure tests
These are Marc Andrusko's, written for investors and repurposed here.
9. Where does shared product end and custom code begin?
Want: a clear line, and a number for what share of a typical deployment is shared.
Worry: vagueness. A vendor who cannot draw the line does not know either, and you will maintain the custom part.
10. What does year-three margin look like on your mature customers?
Want: improving. That means they have been generalising, so what they built for you gets maintained rather than frozen.
Worry: flat. That is a labour business, and your renewal price will reflect it permanently. Revenue per engineer is the metric behind this.
11. How many engineer-months from contract signature to production, on your last three engagements?
Want: real numbers from actual engagements, and a downward trend.
Worry: an average with no engagements behind it, or a number from the plan rather than the outcome.
12. How do you systematically decline customisation requests?
Want: 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.
Worry: that they are customer-led and build what customers need. This is the most revealing answer on the whole list, because a vendor who cannot say no produces a system nobody can upgrade.
Two more if you are buying AI work
What happens when the model is wrong in production? You want an escalation path, a human review step where the stakes justify it, and monitoring somebody actually watches. Vagueness here is the most common reason an AI deployment gets pulled after launch.
Is our data or code used to train anything? Ask explicitly rather than relying on a general confidentiality clause.
How to use the answers
No vendor will answer all twelve perfectly, including us. What you are looking for is whether they have thought about the failure modes.
A vendor who says "we have not solved that, here is how we manage it" is more trustworthy than one with twelve clean answers, because the clean answers on questions 10 and 12 are the ones most easily rehearsed and least often true.
And ask us the same twelve. Our answers: above 80 percent coding time, no bookings component, same people scope and build, both dates in the contract, no completed-handover reference yet because we are new and will not invent one, an eval suite derived from the specification and graded independently, no production access by default, and a stop rule we apply weekly. On year-three margin we have no year three, and saying so is more useful than a projection.
Best for
- Preparing for a vendor call or an RFP shortlist conversation
- Comparing two vendors whose decks look identical
- Deciding what to write into the contract after the call
Avoid if
- You need the evaluation criteria in priority order rather than the full question list
Verify before you commit
- Get the coding-time percentage and the compensation structure as specifics, not descriptions
- Get both dates committed in writing before signature
- Ask for a completed-handover reference and note the answer if there is none
- Ask how they decline customisation, and treat vagueness as the answer
Common questions
What is the most revealing question to ask an embedded engineering vendor?
How do you systematically decline customisation requests? 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, which produces a system that cannot be upgraded and that you maintain after they leave.
What should a vendor say about AI-generated code?
That checks are 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. A worrying answer is that senior engineers review every diff carefully, because that is a claim about attention and attention does not scale with generation volume.
Why ask about year-three margin on mature customers?
Because improving margin means the vendor has been generalising, so what they built for you gets maintained rather than frozen. Flat margin on long-standing accounts means a labour business, and your renewal price will reflect that permanently. It is one of five pressure tests written by an a16z partner for investors.
What reference should you ask for?
One where the engagement ended and the customer's own team took the system over. Every vendor has references from happy ongoing engagements. A completed-handover reference is much rarer and proves the model rather than the relationship. If they cannot produce one, ask how many engagements have ever concluded.
What extra questions apply to AI work specifically?
What happens when the model is wrong in production, where you want an escalation path, a human review step where the stakes justify it, and monitoring somebody watches. And whether your data or code is used to train anything, asked explicitly rather than left to a general confidentiality clause.
How should you interpret a vendor with perfect answers?
With some suspicion on two of them. The answers to year-three margin and to declining customisation are the most easily rehearsed and least often true. A vendor who says they have not solved something and explains how they manage it is usually more trustworthy than one with twelve clean answers.
References
- Marc Andrusko, The Palantirization of Everything, Andreessen Horowitz, 16 January 2026
- Henley Wing Chiu, I analyzed 1,000 forward deployed engineer jobs, Bloomberry, 18 November 2025
- Amazon, AWS invests $1 billion to embed AI forward deployed engineers with customers
- Veracode, spring 2026 GenAI code security research
- First Round Review, So You Want to Hire a Forward Deployed Engineer, 24 February 2026
How a build like this runs
Related reading
The questions to ask before approving an AI build
You are being asked to sign off on a build where most of the code will be generated. You do not need to read the code. You need nine questions and the confidence to keep asking until you get a specific answer.
How to negotiate a software contract you can actually verify
Most build contracts describe effort, timeline, and payment, and leave the one hard question unanswered: on what evidence do you agree the thing is finished?
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.
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.
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.