Forward deployed engineer vs consultant: a decision table

Hire a consultant when you have not yet decided what to build; hire a forward deployed engineer when you know the workflow and need production code written inside your own systems. A consultant's deliverable is advice, and a forward deployed engineer's deliverable is working software in your repositories, so the right choice depends on which of those two things is actually missing.

The distinction is not a matter of seniority or day rate. Both can be senior, both can be expensive, and both can sit with your team for weeks. Illinois Tech's explainer states the difference in one line: "A consultant typically makes recommendations and leaves," while a forward deployed engineer "writes production code in the customer's own systems" (Illinois Tech, What Is a Forward Deployed Engineer?). Wikipedia's entry lists IT consultants among the roles the forward deployed engineer overlaps with, alongside solutions architects, sales engineers and systems integrators, which is why buyers confuse them (Wikipedia, Forward-deployed engineer). Even the role's originator kept the engineer close to the work rather than in the meeting room: the same Illinois Tech article says Palantir historically expected about 25 percent of a forward deployed engineer's time to be spent with customers, which leaves the rest for building. The overlap is real at the start of an engagement, when both are asking questions. It disappears by the second week, when one of them is writing a document and the other is writing code.

If the term itself is new to you, what a forward deployed engineer is covers the definition, the Palantir origin and the day-to-day work. This article assumes you know the shape and are deciding what to buy.

The decision table. Read each row as a question you can answer about your own situation. The column that matches more of your answers is the purchase.

What you get. Consultant: a recommendation, an assessment, a roadmap or a business case. Forward deployed engineer: a working system, built into the tools the team already uses, plus the evaluation suite and documentation that keep it working.

Where the work happens. Consultant: interviews, workshops and documents with your stakeholders. Forward deployed engineer: your repositories, your standups, your tracker and the systems the workflow runs on, alongside the people who do the work.

Who owns the result. Consultant: you own the report; there is usually no production code to own. Forward deployed engineer: you should own every commit, from the first one. If an engineering firm will not assign the IP to you before anyone opens a repository, that is a reason to walk away whichever model you buy.

How success is judged. Consultant: whether the recommendation was sound and whether leadership acted on it. Forward deployed engineer: whether the workflow now runs differently, which is something you can measure in the queue, the cycle time or the hours the team gets back.

What you need before you start. Consultant: a question. Forward deployed engineer: a workflow, an owner for it on the business side, and access to the systems involved. If you cannot name the workflow, you are not ready for an engineer yet.

What happens when it ends. Consultant: you hold a plan that someone still has to build, often a different team with a different understanding of the problem. Forward deployed engineer: you hold software your team runs, and the next decision is whether to keep extending it or bring the work in-house.

The rule. If the sentence "we need to decide whether and where to use AI" is true, buy advice. If the sentence "we know which workflow, we need it working in our systems" is true, buy an engineer. If both are true, buy them in that order and keep the first one short, because the most expensive mistake in this category is paying an engineer to discover that nobody agreed on the goal, and the second most expensive is paying for a strategy that no one is funded to build.

Why buyers get this wrong. The usual failure is not choosing the wrong column; it is buying one and expecting the other. A company hires a consultancy, receives a sound roadmap, and then discovers that the roadmap assumed an engineering team it does not have. Or a company embeds an engineer with a vague brief, and the engineer spends the first month running the discovery a consultant would have done, at an engineer's rate, without the authority to settle the disagreements it uncovers. Both are avoidable by asking one question before signing anything: at the end of this engagement, what will exist that does not exist today? If the answer is a document, you are buying consulting. If the answer is a system in production, you are buying engineering, whatever the proposal calls it.

A third option that is neither. Sometimes the honest answer is that a pilot was already built, by an internal team or a previous vendor, and it stalled before production. That is not a strategy question and it is not an open-ended staffing question. It is a specific set of engineering gaps in a specific system, usually evaluations, guardrails and integration into the systems of record. For that situation Beyond Technologies sells an AI pilot rescue: a one-to-two-week audit of what is salvageable, then a fixed scope over 8 to 12 weeks against one metric agreed up front, and if the build does not move that metric, the build is on Beyond Technologies. It is the only one of the three options with a guarantee attached, because it is the only one with a finish line both sides can measure.

How Beyond Technologies fits the table. Beyond Technologies is an engineering firm, not a strategy consultancy, so it sits in the engineer column. Its embedded engineers are priced day-rate or monthly, with no published rate card; they typically start within one to two weeks of an intro call; the first week is a trial week of real work; there is a four-week minimum and then the engagement runs month-to-month; a two-week replacement guarantee covers fit; and all IP is assigned to the client. For agencies, the same engineer can work white-label, under the agency's brand, with the agency's NDA and non-solicit signed before kickoff. When the question in front of a buyer is genuinely what to build, Beyond Technologies' own recommendation is a short, fixed assessment first, not an engineer.

What it costs to choose. Price rarely decides this well, because the two purchases buy different things. A cheaper consultant who produces a plan nobody builds costs more than an engineer who ships the workflow. The comparison that does help is between an embedded engineer and hiring one full-time, which turns on salary, benefits and how long the work will last. What a forward deployed engineer costs sets that arithmetic out with sourced figures.

If you already know the workflow, the next step is to see the engagement terms for an embedded engineer on the hire a forward deployed engineer page, where the same comparison appears as a table, and book a 30-minute call about that one workflow.