How to choose a forward deployed engineering partner

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 changes the question to the value of customer engagement. The three jobs page covers why this matters most.

Why this question comes first. Everything else on this list only matters if the people doing the work are actually engineers who write code that reaches your repository. A polished answer on dates, verification and accountability from a team that is running presales conversations is a polished answer to the wrong job. Ask this question before any of the others, because a wrong answer here makes the rest of the meeting a waste of time.

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 releases 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.

Push past the first answer. A vendor who names a production date without hesitation but pauses, or asks what you mean, when you ask about handover has told you which date they actually plan for. Follow up with a specific question: "if we signed today, what calendar date would your access to our production systems end?" A vendor who cannot answer that in the meeting has not thought about ending the engagement, which is a different problem from not wanting to.

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 grow as the amount of generated code grows. Eval-driven development is the method to listen for.

A follow-up worth asking regardless of the first answer. Who wrote the checks, and were they written before or after the code they check? A check written after the code exists tends to describe what the code does rather than what it was supposed to do, which is a weaker guarantee even when it passes. A vendor whose checks come from the specification, before a line of code is written, is describing a genuinely different process, not the same process with better wording.

Four: how do they systematically decline customisation?

This is the most useful question on the list, borrowed from a16z's Marc Andrusko, who poses it as an investor 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.

Test the rule with an example, not just the description of it. Ask the vendor to describe an actual request they declined for a past customer, and what they built instead. A vendor who cannot produce a single specific example, even a disguised one, has probably never said no. Saying no is uncomfortable in a sales conversation, which is exactly why a vendor's stated policy and their real behaviour diverge here more than on any other question.

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 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.

Why a named person changes the incentive. A team or a process cannot feel the discomfort of a missed date, but a named individual can, and that discomfort is what makes a delivery date real rather than aspirational. This does not mean one engineer should carry the entire technical risk personally. It means the contract should say, in writing, who at the vendor is answerable if the production date is missed, so the conversation about why it slipped has an owner on the other side of the table.

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 separate, certified teams that pass a defined production-engineering standard, which is meaningful. Most other badges are marketing. Ask what standard was passed and who set it. How the four public programmes describe themselves is the benchmark to compare a smaller vendor against.

Team size. A larger pool of available engineers 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 slide presentation. Ask what happens when the framework's step three turns out to be wrong.

Years in the market. A long history is often presented as reassurance, and for this kind of work it is weaker evidence than it looks. What matters is whether the specific team assigned to your account has done this before, not whether the company as a whole has existed for a long time. Ask about the individuals, not the letterhead.

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.

When you call the reference, ask about the ending, not the beginning. Most reference calls dwell on how the engagement started and how responsive the team was. Ask instead: how did handover actually go, did the vendor's access get fully revoked on the date agreed, and could your own team make a change to the system unaided the week after the vendor left. Those three answers tell you whether the capability transfer was real or only described that way in the contract.

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.