# FDE or Solutions Architect: the dividing line is who commits to production

> Both roles can draw the same diagram. Only one has to open a pull request in the customer's repo and get it running reliably in production.

Bản gốc: https://fdetimes.net/en/guides/fde-vs-solutions-architect-production-commits/

Picture your first kickoff at a large customer. On the table sits a thick architecture design: clean diagrams, every arrow pointing the right way. The question that silences the room is not "is this design right?" but "who opens the first pull request in the customer's repo?"

That question is the dividing line between a Forward Deployed Engineer and a Solutions Architect. Netguru puts it in one sentence: the FDE owns code running in production, while the Solutions Architect produces architecture deliverables. To leave no room for doubt, it adds that the SA produces artifacts, not commits.

For a developer thinking about moving into FDE work, this is the first thing to understand. Many job postings mix "solutions", "architecture" and "customer-facing" freely, so you could take a job drawing diagrams while believing you will be shipping code. Or the reverse.

## Designs don't run. Commits do

Start with what gets delivered. Aced's comparison table puts the two side by side: the FDE delivers a working production system for a specific customer; the SA delivers an implementation plan. On code, the FDE ships and maintains continuously; the SA, according to the same table, usually stops at proof-of-concept.

The timing differs too. Aced places the FDE after the sale, deep in rollout and operations. Anthropic, by contrast, describes its Solutions Architect position as a pre-sales role: a technical adviser to enterprise customers who shapes architecture choices and helps them integrate Claude, without holding the customer's production code.

The two descriptions do not contradict each other; they complement each other. The SA stands before the contract and answers "should we do this, and how?" The FDE stands after it and answers "is it running yet, and why did it just die?"

**Điểm mấu chốt:** Two people can draw the same diagram; only one has to keep it running reliably in the customer's production.

## Companies draw the line with verbs

If you are still in doubt, read the postings from companies hiring for the role. OpenAI's FDE listing in San Francisco asks candidates to own technical delivery across multiple deployments, from first prototype to stable production. The same listing includes writing and reviewing production code across frontend and backend in Python, JavaScript or a comparable stack.

Palantir's FDSE posting describes engineers embedded directly with customers to build applications, LLM workflows and production solutions designed for each customer's reality. It is also clear about the cost: expected travel of 25–50%, depending on team and location.

Capicua names the responsibility more briefly: writing production code directly on the customer's infrastructure and data.

Notice the verbs: own, write, review, build, ship. These FDE descriptions lean heavily towards acting on code, unlike the verb "guide" in Anthropic's SA posting. It is the quickest way to tell the roles apart when you skim a job description on your phone.

## Same problem, two ways in

Take a hypothetical case to see the difference in practice. An insurance company wants to use an LLM to classify and route claims. Both an SA and an FDE are brought in.

The SA sits down with the customer's CTO and asks about volume, SLAs and where data is allowed to go. The output is a document: ingest flow, classification step, routing step, model choice, fallback plan. Perhaps it comes with a proof-of-concept notebook run on a few hundred samples to show the idea is feasible.

The document is approved, the contract is signed, and the SA moves on to the next customer.

The FDE takes that document and clones the customer's repo. They find that the real claims table has a status column nobody mentioned in the document, that the internal auth system blocks new service accounts, and that the nightly pipeline runs before the data has been synced. None of these three things appears anywhere in the design.

The FDE fixes the migration, writes an adapter for auth, changes the schedule, opens a pull request, waits for the customer's platform team to review it, then watches the dashboard through the first week after go-live.

Now consider two replies to the same message from the customer on a Friday afternoon: "The schema just changed, it has to run on Monday." The SA, quite properly, replies that the document needs updating and the estimate revisiting. The FDE replies with a link to a pull request. Both are doing their jobs. They are simply different jobs.

## Check which side you are being hired for

Step one: read the job description and pull out the verbs. If most are guide, advise, design, recommend, it is an SA role even if the title says "engineer". If they are own, write, ship, maintain, debug, it is an FDE role even if the title says "solutions".

Step two: in the interview, ask one specific question: "After go-live, if code I wrote breaks something, who fixes it?" If the answer is "the customer's team" or "the product team", you are discussing an artifact role. If it is "you", it is a commit role.

Step three: ask about timing and location. Do you join before or after the contract is signed? Does the code run on the customer's infrastructure or in your company's demo sandbox? What share of your time is spent on site with the customer? Palantir answers the last question in its job description; where things are vague, you have to ask.

Step four: write your CV by the same logic. A line such as "designed the architecture for system X" tells an FDE hiring manager that you produce artifacts. A line such as "shipped system X to production at customer Y and maintained it through three releases" says you produce commits and take responsibility for them. The second line is what they are looking for.

## Common mistakes

The biggest mistake is thinking an FDE is just "an SA who can code". It isn't. Many SAs are excellent coders. The difference lies not in skill but in whose name is on the commit that actually runs, and who has to answer when it breaks. A proof-of-concept running on a laptop, however good, is still an artifact.

The second mistake is treating a pre-sales demo as a deployment. A demo exists to prove capability and close the deal. A deployment exists to survive the customer's dirty data, unfamiliar auth and batch schedules. If all your "customer-facing" experience is demos, you do not yet have evidence for an FDE role.

The third mistake is dodging operational responsibility once you are an FDE. Aced places the FDE "deep in rollout and operations" for a reason. If you ship and then vanish, you are doing an SA's job with an FDE's level of risk.

## This week's exercise

Open your CV and mark each line of experience: which lines describe artifacts, and which describe commits that actually ran. Pick one artifact line and rewrite it as something you shipped and maintained, or admit that you do not yet have that evidence.

A design tells you how a system should run. The FDE is the one responsible for making it run.

**Thử ngay tuần này:**

- Take three job postings (one FDE, one Solutions Architect, one with an ambiguous title), underline every verb describing the work and sort them into two columns: 'produces artifacts' and 'produces commits'.
- Pick a design document you have written and turn one section of it into a real pull request, with tests and a reviewer.

## Nguồn

- [Forward Deployed Engineer vs Solutions Architect: Hire the Right Role](https://www.netguru.com/blog/forward-deployed-engineer-vs-solutions-architect)

- [Forward Deployed Engineer vs Solutions Architect (2026)](https://www.aced.io/blog/forward-deployed-engineer-vs-solutions-architect)

- [Solutions Architect, Applied AI (Anthropic)](https://jobs.generalcatalyst.com/companies/anthropic/jobs/90192193-solutions-architect-applied-ai)

- [Forward Deployed Engineer - SF (OpenAI, Built In)](https://builtin.com/job/forward-deployed-engineer-sf/4457354)

- [Forward Deployed Software Engineer (Palantir)](https://jobs.lever.co/palantir/5168e8fd-fec1-4fea-b7a1-81bdaea65850)

- [About The Forward Deployed Engineer Role](https://www.capicua.com/blog/the-forward-deployed-engineer-role)