Three Questions to Ask Before You Let a Vendor Embed an Engineer in Your Codebase

Last week AWS announced a billion dollars behind a new Forward Deployed Engineering org. Pods of five or six engineers, dropped directly into a customer's environment, gone in a matter of weeks with a "self-sufficient" team supposedly left behind. This isn't anything new, OpenAI and Anthropic have their own FDE unit. They didn't invent this model, Palantir did, over a decade ago. AWS just put a billion dollars behind it, and that's a different kind of signal. When a hyperscaler funds a labor model at that scale, it stops being a trend and becomes a default.

And I am going to be honest here, I don't think this is a bad idea. I've watched a vendor engineer walk into a codebase and solve in three weeks what an internal team had been circling for six months. It's amazing what fresh eyes with no internal politics and no "well that's how we've always done it" mentality can do.

But there's a question nobody asks in the sales conversation, and it's the only one that actually matters: when that engineer ships code to your production system and then goes back to their company, who's optimizing for what?

Not who cuts the check. I mean, in the moment they're making a decision in your codebase, what does success look like for them? Because it's almost never "this team can operate without me in three years." It's proving the platform works, or hitting a renewal milestone, or maybe generating a case study. Those are good goals for their employer, but they are not the same goal as yours. And that mismatch doesn't go on a sales deck.

So with all that said, that's my framing for this article. It's not "should you do this" but, "What are you actually buying, and what's the bill that comes due later?"

But I promised you three questions that I'd ask before signing...

1. What are the exit criteria, and does it include your team operating this alone?

Most FDE contracts define success as "the system works." That's the wrong bar. A running system and an understood system are two different things, and the gap between them is exactly where you'll get burned.

I've seen this play out the same way more than once. An expert builds something fast, using patterns that are idiomatic to the platform they came from. It works beautifully. And then, three months later one of your engineers needs to change a field, a parameter, something small, and they stare at the code with no idea why it's structured the way it is. The documentation describes the platform, not the decisions. The change gets made anyway. It's fine... until it isn't.

The exit criteria has to name this explicitly: can your team be paged on this at 2am and handle it, not just watch it run. If the contract only measures whether the system is live, you're buying a running system, not a transferable one. Those are different products sold at the same (expensive) price.

2. How is the FDE incentivized, and what happens at renewal?

This isn't a rude question, it's due diligence. If the person embedded in your codebase is measured on whether you renew, they have a quiet incentive to stay indispensable. If they're measured on knowledge transfer, they have an incentive to make themselves replaceable.

What to ask:

What does success look like for your team at the end of this engagement?

And then listen for whether the answer includes your team's independence, or just platform performance metrics. You will get a very different answer depending on how that engineer's next quarter gets scored, and you're entitled to know which one you're getting before you sign.

3. Who owns the decision log?

Not API documentation, your platform vendor already has that. I mean the record of why this abstraction and not that one, why this service boundary, why this data model, in your specific environment. That's the artifact that actually matters, because it's the only way the next engineer on your team can reason about the system without reverse engineering every choice from scratch.

Most engagements don't include this by default. If the vendor says a decision log is out of scope, that answer tells you something on its own. Ask for it. Then decide who on your team owns reading it before the FDE leaves the building.

What good actually looks like

Asking better questions doesn't help if you don't know what you're asking toward. The best forward deployed engineers work themselves almost out of a job, on purpose. Every design review includes explanation. Every architectural decision has an owner on your team, not just on theirs. By the last month of the engagement, they're pairing instead of leading, asking your engineer "what would you do here" instead of just answering.

You can see this early in the engagement. In the first thirty days, are they documenting as they go, or is documentation a deliverable tacked on at the end? By month two: is there someone on your team who can explain the core architecture to someone new without checking with the FDE first? If that person doesn't exist by month two, the knowledge isn't transferring, it's accumulating in one place, and that place is leaving. Soon.

You also need to watch how they handle disagreement. In a bad engagement, they implement your team's call quietly and move on, which sounds professional right up until the thing they disagreed with is load-bearing and nobody wrote down why. In a good one, they name the trade-off, defer to your team, and log the reasoning either way. That's not extra work, that's the job.

And the handoff itself should be a week, not just a document. A week where your team runs the system while the FDE watches, and the questions start flowing the other direction, is a test.

Now let's be honest about what you're buying when you bring in a forward deployed engineer: time. Time to get something into production while your team figures out the platform. That's a real thing worth paying for. Just know the debt doesn't disappear when the engagement ends. It sits there until someone on your team pays it down, usually at 2am, usually without the person who wrote the original code on the call.

If you're sitting across from a vendor account team with a contract in front of you, this is the one question underneath all three: when this person leaves your building, can your team operate, maintain, and extend this system without calling them back. If the answer is yes, you have a deal. If the answer is "we'd recommend an extended engagement," that's also an answer (just a different one.)

A running system is not an understood system. Production isn't the finish line. Understanding is.