Forward Deployed Engineer vs Solutions Engineer vs Consultant

The short answer: a solutions engineer proves the technology can work and is measured on closed deals, a consultant recommends what should be done and is measured on the quality of the decision, and a forward deployed engineer builds the system inside your environment and is measured on whether it still moves your metric a quarter later. All three sit in front of clients and all three are technical. They own completely different things, and hiring the wrong one for AI delivery is the most common and most expensive staffing mistake in the category.

Here is how to tell them apart and how to pick.

Related reading: what a forward deployed engineer actually does, AI consultant vs. in-house hire, and hiring AI talent vs. buying services.

The one-line difference

• Solutions engineer. Output: a proof that it can work. Measured on: deals closed and technical win rate. Sits pre-sale, alongside an account executive.
• Consultant. Output: a recommendation and a plan. Measured on: decision quality and client satisfaction. Sits before and around the work.
• Forward deployed engineer. Output: a running system in production. Measured on: the business metric, a quarter later. Sits inside the delivery, in your repos.

If you remember one thing: the solutions engineer's job ends when you sign, the consultant's job ends when you decide, and the forward deployed engineer's job ends when the thing works in production and your team can run it.

Solutions engineer: proving it can work

The solutions engineer, sometimes called a sales engineer or pre-sales engineer, exists because complex technical products cannot be sold by a salesperson alone. They run the demo, build the proof of concept, answer the security questionnaire, and handle the objection from the buyer's staff engineer who wants to know how the retrieval actually works.

They are genuinely technical and often excellent. But their incentive is to demonstrate feasibility, not to guarantee durability. A proof of concept is optimised for showing the happy path convincingly. That is the correct optimisation for their job and the wrong one for yours after signature.

The failure mode is well known to anyone who has bought enterprise software: the pilot the solutions engineer built worked beautifully, and the production rollout that followed did not resemble it. Nobody lied. The POC was built on clean sample data with the hard cases removed, because removing hard cases is what makes a demo land.

Consultant: deciding what should be done

A consultant's leverage is analysis, framing and experience across many companies. They are worth paying when the question is genuinely contested, when the decision is expensive and hard to reverse, or when you need an outside read your internal politics cannot produce.

Their output is a recommendation: a prioritised roadmap, a build-versus-buy call, an operating model. Good ones are extremely valuable. The structural weakness is that the recommendation is validated by argument rather than by contact with your system. A plan can be internally coherent, well-researched, and still wrong about your data in a way nobody discovers until an engineer tries to build against it.

This is why the two-stage pattern of a strategy engagement followed by a separate implementation vendor fails so often. The people who wrote the plan never had to live with it, and the people living with it did not write it.

We wrote more on this in AI consultant vs. in-house hire.

Forward deployed engineer: making it work in your environment

A forward deployed engineer embeds in your team and builds inside your stack. Not a sandbox, not a parallel environment. Your repos, your cloud, your warehouse, your on-call rotation.

The consequence is that they cannot avoid the things that kill AI projects. They meet your inconsistent event schema in week one. They discover that the field everyone treats as reliable has been null for 14% of rows since a migration in March. They watch an operator work around the process the design assumed. None of that appears in a plan, and all of it decides the outcome.

Because they can change the code, their feedback loop is days rather than quarters. A wrong assumption in a consulting plan surfaces at the end of implementation. A wrong assumption in FDE work surfaces the first time the pipeline runs.

Which one you actually need

Ask what your bottleneck is right now.

You do not know whether the technology can do the job. You need a solutions engineer, usually the vendor's, and you should not pay separately for it. Give them your worst data, not your cleanest, and the demo becomes far more informative.

You do not know what to do or in what order. You need consulting. If your problem is genuinely a prioritisation problem across a portfolio of possible bets, an outside view is worth real money. Our writing on how to prioritize AI use cases covers the framework we use.

You know what to build and it keeps not happening. You need forward deployed engineering. This is the most common state for mid-market companies in 2026: the strategy deck exists, the use case is agreed, and eighteen months later nothing is in production. Another plan does not fix that. MIT's finding that 95% of AI pilots deliver no measurable business impact is a delivery statistic, not a strategy one.

The hybrid trap

A word of warning about the middle option, because it is popular and it usually disappoints.

Many firms now offer a consultant who "also implements," or a solutions engineer who "stays on through delivery." Sometimes this works. Often what you get is someone doing two jobs badly, because the two jobs demand different things at the same moment. When delivery gets hard, the consultant instinct is to re-frame the problem and the sales instinct is to protect the relationship. The engineering instinct is to open the trace logs at 11pm and find out why retrieval is returning garbage on 8% of queries.

The test is not what the role is called. It is what happens when the work goes badly. Ask a prospective partner to describe an engagement that went wrong and what they personally did in the fourth week. The answer separates the categories faster than any credential.

What this means for how you buy

Three practical rules.

• Buy the accountability, not the title. Write the success metric into the contract. If a partner will not attach their fee to a number in your system, they are selling one of the first two roles regardless of what the proposal says.
• Insist on your environment, early. Any partner who wants to work in their own sandbox for the first month is deferring every risk to you. The correct sequence is to hit your real data in week one, when the scope can still change.
• Watch the handoff count. Every person between the model and the metric is a place information dies. The forward deployed model exists specifically to make that count zero.

Frequently asked questions

Is a forward deployed engineer just a consultant who codes? No. The difference is accountability, not activity. A consultant is accountable for the quality of the recommendation. An FDE is accountable for a system that runs in production after they leave, which changes what they choose to work on almost daily.

Can the same person be a solutions engineer and a forward deployed engineer? The skills overlap heavily and people do move between the roles. Holding both at once on the same account is the problem, because pre-sale optimism and delivery honesty pull in opposite directions when something is not working.

Which role is more expensive? Forward deployed engineers usually cost the most per hour, because the combination of engineering depth, client-facing judgment and ambiguity tolerance is rare. They are also the only one of the three whose output is a system you keep, which is the comparison that matters. See what a real AI consulting engagement costs.

Do I need all three? Rarely, and almost never at once. Most mid-market companies need a short prioritisation exercise followed by real delivery. If a proposal has all three roles staffed on a single project, you are paying for coordination overhead.

How do I know an FDE engagement is working? Something is running in your environment within the first few weeks, and there is a dashboard showing a business number rather than a model score. If neither exists by week four, the engagement has quietly become consulting.

10dem staffs forward deployed engineers by default, and we attach our work to a metric in your system. If that is what you are looking for, get in touch or read about our services.