Forward Deployed Engineer vs Solutions Architect vs Consultant

You have three job postings open. One says Forward Deployed Engineer. One says Solutions Architect. One says Technical Consultant. All three mention customers, architecture and code. They sound like the same job.

They usually aren't. And the title won't tell you which is which. One company's FDE is another company's customer engineer, applied AI engineer or senior solutions architect.

What tells you the job is four things: what the person is responsible for, when in the customer relationship they show up, how much real production code they write, and how their success gets measured. This guide compares five roles on those four things, walks through one made-up customer to show where each role fits, then gives separate advice for people choosing a job and people hiring for one.

The five roles at a glance

Dimension	FDE	Solutions Architect	Implementation Engineer	Consultant	Core Product Engineer
Starts from	A result the customer needs	Whether the product fits	A rollout that's already defined	A client's problem or program	The product roadmap
When they're involved	From discovery until people are using it	Before the sale, through the design handoff	After the sale, through go-live	Project start to final deliverable	All the time
Coding	Production code	Prototypes and examples	Integrations and configuration	Varies	Production code
Accounts per person	Few, deep	Many, broad	Several live rollouts	One or a few projects	None
What they hand over	A working system people use	An architecture and proof it fits	A configured, launched product	A recommendation, a change, or delivered work	A product feature many customers use
Judged on	The customer's result, plus lessons that improve the product	Proving fit and moving deals forward	How fast and how cleanly go-live happens	The project's goal	Product impact and reliability
Product feedback	Direct and expected	Frequent, usually advice	About day-to-day operations	Indirect	Owns building the roadmap

These are defaults, not laws. The sections below show how to check them at a real company.

Forward deployed engineer: owns the result and builds it

An FDE starts with a result the customer needs and stays until it works, people use it, and someone can measure it.

Along the way the same person might figure out the actual problem, design the system, write the data pipeline, build the app, write tests for the model's output, get through the customer's security review, train users, and watch the rollout.

That sounds like too many jobs for one person. It makes sense when the situation is messy. Every handoff between people loses something. When a deployment depends on dozens of small decisions that need context, one trusted owner moves faster than five specialists passing documents back and forth.

Companies describe it in their own ways. Palantir describes its FDSEs as engineers focused on one customer across many capabilities. Ramp extends the idea across the whole customer lifecycle, and frames the choice as a quick fix for one customer versus a product feature for all of them. OpenAI's FDE posting runs from discovery and scoping through system design, build, production rollout, adoption, and feedback that changes the product and model roadmap.

Solutions architect: proves the product fits

A solutions architect usually covers more deals, earlier. They turn a customer's business and technical needs into a design, show the product fits, flag the risks, build demos or small proofs of concept, and lay out a believable path to getting it live.

Solutions architects can be excellent engineers. The difference isn't skill. It's time. Sales needs coverage across many deals, so an SA can't move into one customer's production build for months. Their value comes from solving the same technical question again and again, across accounts.

The handoff test is the simplest way to tell. If the person is expected to stop once the customer agrees the product fits, and hand the build to another team, that's solutions architecture. If the same person owns the build, the rollout, getting people to use it, and the result, that's closer to FDE.

Implementation engineer: a known path to go-live

Implementation engineers turn a product someone bought into a working setup for that customer. They configure it, connect it to other systems, move data over, test, train people, and run the launch.

The difference from FDE work is how much is unknown. Implementation starts with a known product and a rollout pattern that's already been figured out. FDE work starts where the product, the workflow or the technical path still has to be discovered and built.

Good implementation teams matter. Companies often create an FDE role when what they really need is a better implementation team.

Consultant: works on the client's problem, not one product

Consulting covers a huge range, from strategy advice to hands-on technical work. A consultant might map how a company operates, build a data platform, lead an organizational change, or bring industry knowledge that has nothing to do with any vendor's product.

The key difference is who they work for. An FDE usually works for a product company and uses customer work to make that product more valuable. A consultant works on the client's problem, and might recommend different technology, a different vendor, or a reorganization.

Consultants tend to work from a statement of work, a contract that spells out what they'll deliver. FDEs more often work inside a product subscription or a strategic partnership.

The two can work side by side. A consultant might lead a company-wide change while the vendor's FDE builds the product-specific system underneath. Trouble starts when neither side owns the production result, or both assume the other one does.

Core product engineer: one feature for many customers

Core product engineers build the platform itself. They optimize for reuse, reliability, easy upkeep, and a roadmap that serves many customers at once.

Staying away from individual accounts protects their focus. It also means they see less of where the product actually works or breaks.

FDE and product engineering work best as a loop:

The FDE runs into friction at a customer.
Both teams decide whether it's a one-off, something reusable, or a sign the product is missing something.
The FDE builds a local fix, or a fix at the platform level.
Core engineering owns whatever change belongs in the product.
The new feature makes the next deployment easier.

Without that loop, FDE turns into a custom-services team cut off from the product. Without time in the field, product engineering builds things that miss how customers really work.

One customer, five roles: a made-up example

Here's how the roles might line up on one deal. The company and the numbers are invented.

An insurance company wants an AI assistant that reads incoming claims and drafts a first response. It's looking at a vendor that sells an AI platform.

Before the sale, the vendor's solutions architect runs discovery. They learn the claims live in an old system with no modern API. They sketch a design, build a small demo on sample claims, and show the platform can do the job. The insurer signs. The SA moves on to the next deal.

After the sale, nobody has connected this platform to that claims system before, and nobody knows exactly what a "good" draft looks like to the insurer's adjusters. That's FDE territory. The FDE spends weeks inside the customer's environment, writes the connector, builds the drafting workflow, sets up tests with real adjusters, gets it through security, and stays until adjusters actually use it.

Back at the vendor, the FDE notices that three other insurance customers are asking for the same connector. The FDE and core product engineering agree it belongs in the product. Product engineering turns it into a supported feature.

For the next customers, the path is now known. Implementation engineers configure the connector and the workflow from a playbook. No FDE needed.

Meanwhile, the insurer has hired a consulting firm to redesign its whole claims process, including which teams handle which cases. That work is bigger than any one vendor's product. The consultant and the FDE need to agree on who owns the assistant once it's live.

Notice what happened. The same deal used every role, each for the part it's built for. The trouble starts when one role is stretched over a part it isn't built for, like an SA asked to own a months-long build, or an FDE asked to hand-build the same connector for the fifth time.

Five questions that reveal the real role

Use these in an interview, or when writing a job description. The title matters less than the answers.

1. What ends the engagement?

FDE: the result is running, measured and handed off, or the team picks a new important problem on purpose.
Solutions architect: the technical decision is made and the path to getting it live looks believable.
Implementation: the configured product is accepted and handed to whoever runs it day to day.
Consulting: the contracted deliverables are done.

2. Whose code reaches production?

Ask who owns the production code, who gets paged when it breaks, who handles the security review, the tests and the upkeep. Prototypes that get handed off point to solutions architecture. Owning production is a strong FDE signal.

3. How many accounts does one person carry?

Deep ownership and a long account list don't mix. An FDE might touch several deployments. But owning a big portfolio for the long haul usually pushes the role toward architecture, training customers, or account support.

4. How is performance measured?

Closed revenue points to sales engineering. Go-live dates point to implementation. Billable hours point to consulting. Whether customers actually use the system, the difference it makes to their operations, and lessons that feed back into the product point to FDE.

5. What happens to repeated work?

In a healthy FDE setup, doing the same thing twice is a signal to turn it into product, automate it, or write a standard playbook. If the team celebrates doing the same custom work over and over as growth, it's building a services business, whatever leadership calls it.

If you're choosing a job

Choose FDE if you like messy problems, talking to customers, building the whole stack, learning a new industry fast, and owning the result yourself. You trade some technical depth and focus for range.

Choose solutions architecture if you like designing systems, explaining them, switching between many customers in a week, and shaping lots of deals without owning every production detail.

Choose product engineering if you want to own a system for a long time, go deep on hard technical work, and build something many customers use.

Choose technical consulting if you want varied problems, a wider view of how organizations work, and the freedom to recommend any vendor or approach.

No role is automatically more technical or more strategic. A well-designed job can be great under any title. So ask about it directly: how a typical week splits up, how much production code you'd write, travel, how many accounts, what you get to decide, on-call, how you're measured, and the last three projects the team actually delivered.

If you're a solutions architect thinking about FDE work, you likely already have the discovery, design and customer skills. The usual gap is writing production code week after week, and owning a deployment after the customer has said yes. A portfolio of tested, monitored systems that run in production is the best way to show you can close it.

If you're hiring

Start with the bottleneck, not the title.

Deals fail technical evaluation: hire a solutions architect.
Signed customers take too long to set up: hire or improve implementation engineering.
Key customers need new production systems built on your platform: consider an FDE.
Customers need vendor-neutral strategy, a redesign of how they operate, or a large change program: use consultants.
Most customers need the same missing feature: invest in product engineering.

Sometimes the answer is a sequence, like the insurance example above. A solutions architect proves fit, an FDE builds the first new kind of deployment, product engineering turns the pattern into a feature, and implementation rolls it out to everyone else. Clear start and end points for each role keep the overlap from turning into confusion.

An FDE fits when the problem is valuable but nobody has scoped it yet, the build needs real custom engineering rather than configuration, the customer matters enough to justify deep time, and what the FDE learns could improve the product.

Know when not to hire one:

The rollout is repeatable and already documented.
The account can't justify scarce engineering time.
The customer expects unlimited custom development.
The company has no way to turn repeated work into product.

Don't let the reporting line define the role. An FDE can report to engineering and still end up doing technical account support. A solutions architect can report to sales and still ship production-quality code. Define the role by what it owns, how its time is split, and what it's expected to deliver.

Either reporting line can work if the incentives are spelled out. Reporting to sales keeps the work close to revenue, but can push toward one-off customizations. Reporting to engineering protects quality, but can slow things down. Many teams solve this with a customer engineering group tied closely to both product and go-to-market leaders.

Read the FDE hiring decision framework before opening a role, and use the team design guide to settle who hands what to whom before the first person starts.