Forward deployed engineer: what it is, and when to hire one vs an agency

Where the model came from

Palantir invented forward deployed engineering in 2005 because its first customers, US intelligence agencies, had problems that traditional consultants could not solve. The work required someone who understood the domain deeply and could write production code inside a classified environment. Splitting that across a consultant and an engineer did not work, so Palantir stopped splitting it.

The model stayed niche for fifteen years. Then AI products arrived with the same shape of problem: enormous capability that produces no value until someone wires it into a specific company's messy reality. In early 2025 OpenAI stood up a Forward Deployed Engineering team, and Anthropic, Google Cloud and Stripe now staff comparable roles. a16z calls the pattern services-led growth: trading gross margin for a moat that competitors cannot copy from the outside. The Pragmatic Engineer has the best account of what the job is like day to day.

Worth naming the incentive, because it explains the whole category: a vendor deploys FDEs to make their own product succeed inside your company. That is the original meaning of the term, and it matters when you start shopping for one.

What the job actually involves

Three things, and they are usually done by the same person on purpose:

• Discovery and integration. Interviewing the people doing the work, mapping the actual workflow rather than the documented one, and getting into the real data pipelines.
• Hands-on building. Production code in the customer's environment, wired to their APIs, inside their security constraints.
• Feedback to the core product. Carrying friction back to the product team so the next customer needs less custom work.

Notice that the third only exists if you are a software vendor with a core product. For everyone else it is irrelevant, which is the first clue that "hire an FDE" is often the wrong framing for a company that just needs better internal tools.

Three ways to buy forward-deployed engineering

The term has outrun its origin, and there are now three genuinely different things being sold under it.

Most of the market currently sells the middle option. Search "hire forward deployed engineers" and you will find staffing marketplaces promising vetted profiles in 48 hours and offshore providers advertising steep discounts. That is a real service and sometimes the right one. But note what is being sold: a person, not an outcome.

The question that actually decides it

Are you buying capacity or an outcome?

If you can already write the specification, you are buying capacity. Staffing is cheaper and you should use it. You will spend your own time on direction and review, and that is a fair trade.

If the hard part is figuring out what to build, you are buying an outcome, and handing a contractor an underspecified problem is how six weeks disappear. The reason discovery matters is that the people who understand the workflow usually cannot describe it in a document. They can only show you, while doing it. That is a different skill from writing the code, and the whole point of the FDE model is that one person or one small team does both.

What "forward deployed" should mean in practice

The label is being applied to a lot of ordinary outsourcing. Six things separate the real thing, and every one of them is checkable before you sign:

1. They work against your real data, in your environment, not a sandbox with sample rows.
2. They talk to the people doing the job, not only the executive sponsor who approved the budget.
3. Something usable exists in week one. Not a document about what will exist later.
4. They own permissions and data scoping. "Each manager sees only their own accounts" is a data-model question and the most common place fast builds fail.
5. They stay through adoption. Shipping is half the job; the other half is people actually using it in month three.
6. You own the code at the end. Repository, environment access, and a written data model transfer to you.

Where it goes wrong

• Sold as embedded, delivered as consulting. The engagement ends in a recommendation deck. If nobody logs into anything, it was consulting.
• An engineer with no access. Dropped into your company without a domain guide, real data, or the authority to talk to end users. Competent people fail at this reliably.
• The prototype that never becomes production. Impressive demo, no auth, no permissions, no error handling, quietly abandoned.
• Nobody owns adoption. The tool works and nobody uses it, because usage was never anyone's job.

We wrote about the last one at length in the buyer's guide to custom GTM tools, because it is the single most common reason internal tooling dies.

How we work, for the sake of being concrete

Gloo is the third option, narrowed to one domain. We embed with go-to-market teams, sales, account management and customer success, build in their existing stack against their real data, ship a working tool in two to three weeks, and stay through adoption. We are not FDEs in Palantir's original sense, because we are not deploying our own product into your company. We use the same method for a different purpose: your internal tools instead of our software.

If you want the unglamorous version of what that timeline really looks like, including the parts that took longer than expected, the build log is a commit-by-commit account of one real project.

If you take one thing

The valuable part of the FDE model was never the job title. It was the decision to stop separating the person who understands the problem from the person who writes the code. You can buy that as an employee, as a contractor, or as a team. What you cannot do is buy it from anyone who wants to hand you a document at the end.