Forward Deployed Engineering: Should You Build or Partner

Forward deployed engineering has become one of the most talked-about delivery models in enterprise software. OpenAI and Salesforce both run it in some form, whether as a dedicated deployment team or under a different title.

However, it’s not as easy as it sounds. Growing a forward deployed engineering function from a couple of engineers to a dozen or more typically takes well over a year, not a quarter or two. If you’re evaluating this decision right now, you likely don’t have that kind of time to spare.

The real question, then, isn’t whether the model works. It’s whether you build it internally or bring in a partner who already has it.

This article will walk you through what the model means, what building it internally really costs, the signals that tell you when you don’t have time to build, and a framework for choosing between building, partnering, or a hybrid.

What forward deployed engineering actually means

Forward deployed engineering is a delivery model, not a job title. Engineers embed directly inside a customer’s environment to build, integrate, and own production software until it delivers a measured business outcome. What matters isn’t whether you need a person with this staff title. It’s whether your organization needs this delivery model at all.

The approach is closely associated with Palantir, which pioneered embedding engineers directly with clients rather than handing off a specification for someone else to build. Naming varies by company. Palantir originally called these engineers “Deltas,” while Anthropic uses the title Forward Deployed Engineer organized under its Applied AI team.

According to Databricks, its forward deployed engineers migrated more than five petabytes of data and over 500 notebooks for JPMorgan Chase’s Consumer & Community Banking division. The work took four months and included training more than 600 of the bank’s users on the platform. That’s the model in action, not theory. Engineers sit inside the customer’s systems, write production code, and race a deadline the customer feels directly, not one buried in a project plan.

How it differs from a solutions architect, sales engineer, or consultant

Forward deployed engineering keeps getting lumped in with solutions architects, sales engineers, and consultants, since all four sit close to the customer. But the real distinction isn’t who talks to the customer. It’s who owns the outcome once the contract is signed.

A solutions architect designs the integration plan and hands it off. A sales engineer builds a proof of concept to help close a deal, then moves on to the next prospect. A consultant is typically engaged to produce a recommendation or a deliverable, not to stay accountable for whether that recommendation works once implemented.

In practice, this means that whoever you choose, either an internal team or a partner, is on the hook for the result in production, not just the plan for getting there.

It’s also worth separating forward deployed engineering from IT staff augmentation, since the two get pitched interchangeably and shouldn’t be. Staff augmentation adds headcount that you direct, inside your own process, toward your own backlog.

A forward deployed engineering partner works the same ground, inside your environment. But it takes ownership of a specific outcome instead of taking direction from your backlog. One rents capacity. The other owns a result.

Why forward deployed engineering is suddenly everywhere

AI adoption is producing a specific, well-documented failure pattern: an AI model that performs well in a demo and then stalls the moment it meets a live production environment. If that sounds familiar, that’s exactly the gap forward deployed engineering closes.

Enterprise software has always tended to fail at the integration layer rather than the product layer. Legacy systems, security review, hybrid cloud setups, and data governance requirements are where deployments stall, not the core functionality of the software itself.

AI makes this failure mode worse rather than better. A model that performs well against clean, curated data in a sandbox routinely struggles against fragmented and inconsistent systems. That gap between a working prototype and a working deployment is where most AI rollouts stall.

This has changed how B2B software companies pitch growth. The pitch is shifting from “here is our product” to “here is the outcome, and we will make it work inside your environment.” Palantir, Databricks, Salesforce, OpenAI, Anthropic, and Ramp all now run a dedicated forward deployed engineering function, which means the model isn’t a single-company experiment.

What it actually costs to build an internal team

Building forward deployed engineering in-house is a long-term organizational commitment, not a hiring line item, and that real cost is easy to skip past when you’re the one evaluating it.

1. Headcount. You won’t fill this with a single hire in a quarter. You need multiple senior engineers who can build and own a stakeholder relationship at once, a combination that’s genuinely rare. Recruiting from Scratch’s placement data puts the median base salary at $210,000, with senior and staff hires going well above that.
2. Time. This capability compounds. It doesn’t switch on the day you finish hiring. Your team needs real experience to know when to scope a request down, when to build a one-off fix versus a reusable feature, and how to earn the trust to push back on a bad ask. According to Ramp’s Builders Blog, it grew from 2 engineers to 16 in about a year and a half after the function launched in fall 2023, at a company already succeeding at enterprise sales.
3. Opportunity cost. Every month you spend building is a month your own AI rollout, migration, or integration doesn’t ship. If you have a deadline attached to it, that cost is real, not abstract.
4. Organizational design. Deciding where this function reports into product, engineering, or operations, and how it avoids overlapping with existing teams, takes multiple quarters to settle, and you’ll need to resettle it as your team grows.

Four signs you don’t have time to build

You might not need to work through this decision slowly. A few signals mean the build path isn’t realistic, regardless of budget.

1. A specific rollout or deadline is already on the clock. If your AI rollout, migration, or integration has a deadline measured in a single quarter, a build timeline measured in years is not a real option.
2. Your best engineers are already fully allocated to the product. Pulling senior engineers into a new embedded delivery function means either the product roadmap slips or the new function ends up staffed with people who aren’t strong enough to do it well. Neither is a good trade.
3. You don’t have a pipeline for the hybrid skill set. Engineering fundamentals, business fluency, and judgment rarely show up in the same candidate, and most hiring funnels aren’t built to find or screen for that combination.
4. You need to prove the model fits before investing in building it. Standing up a full internal function before knowing whether forward deployed engineering suits your organization’s environment is a bet most companies shouldn’t make blindly.

If two or more of these apply, the decision in the next section becomes considerably easier.

Build, partner, or hybrid: A decision framework

This is the decision that matters, and it’s rarely a permanent, one-time choice.

You don’t need to choose once and stop. The most common, underrated path is starting with a partner to prove the model works and hit a near-term deadline. Then, build internal capability once deployment volume justifies the fixed cost of full-time headcount. Treat “build” as the end state of a maturity curve rather than the default starting point. Revisit the decision as your internal deployment pipeline grows, rather than locking it in based on where you are today.

What to look for in a forward deployed engineering partner

Not every implementation or professional services engagement is actually forward deployed engineering. The distinction determines whether you get an outcome or a deliverable.

Owns the code, not just the plan

A real forward deployed engineering partner writes and owns the code running inside your environment. That’s different from a partner who produces a scoping document and hands it to your internal team to build. If the engagement’s output is a recommendation rather than working software, it isn’t this model, regardless of what it’s called in the proposal.

Embedded day-to-day, with a real feedback loop

The team should be embedded in your systems daily, not producing periodic status updates from a distance. Ask specifically how the partner captures what they learn on-site and routes it back into your product roadmap. If there’s no real mechanism for that feedback loop, you’re paying for a single project rather than a repeatable capability.

Speed to a first working outcome

This is the entire point of choosing a partner over building internally, so measure it directly. A partner engagement that still takes a year to produce a first outcome has defeated its own purpose.

Especially in system integration and legacy-environment work, where advisory-style engagements often fail to become production reality. A client is handed a plan, and the plan never quite becomes running software.

A partner delivering genuine forward deployed engineering should point to a specific, working outcome within weeks of starting, not a roadmap for getting there eventually.

That’s the standard forward deployed engineering partners should be held to. It’s how Eastgate’s AI and intelligent automation practice runs its embedded engagements, with engineers working inside a client’s environment and owning production code from the first sprint.

Final thoughts

Forward deployed engineering is a genuinely useful delivery model, but the decision that matters isn’t whether to adopt it. It’s whether your organization has the year-plus runway and dozen-plus specialized hires it takes to build the capability internally, or whether outsourcing the outcome gets you there faster right now.

Don’t treat build versus partner as a permanent choice. You’ll get the most out of this model if you start with a partner to prove it quickly. Bring the capability in-house only once your deployment volume justifies the fixed cost of a full team. Building is the end state of a maturity curve, not the starting line, and revisiting that decision as your deployment needs grow is a sign of good judgment.