Forward Deployed Engineer vs Software Engineer (2026)

Forward deployed engineers and software engineers write the same kind of production code. They differ in who they build for, where the code runs, and who decides whether it worked.

Short answer: A forward deployed engineer (FDE) builds for one customer, often inside that customer's environment, and is measured by go-live and business outcomes. A software engineer builds the product every customer uses and is measured by delivery, reliability, and scale.

Key takeaways:

• Travel: FDE postings typically name 25% to 50% travel (median 40% across the 52 postings in our sample that name a number). Software engineering postings rarely mention it.
• Pay: on Levels.fyi, U.S. FDEs report a median of $216,250 against about $197,000 for software engineers (October 2026). The FDE sample is small and tilted toward high-paying companies, so the gap is weak evidence of a premium.
• Code: the FDE's code stays with one customer and needs an owner there after the engagement. What travels back to the product team is the pattern behind it.
• The sharpest blocker: a customer web app with no API and a login tied to the user's own machine.

What is the difference between a forward deployed engineer and a software engineer?

Palantir, which pioneered and popularized the modern FDE model, puts it as "one capability, many customers" for a product engineer and "one customer, many capabilities" for a forward deployed engineer, as quoted by The Pragmatic Engineer.

Take an illustrative case (our composite): an AI vendor hires two engineers in the same week. The first joins a product team, and their week is bounded by the product: a known repo, a roadmap a quarter ahead, and success defined as a merged change that holds up for everyone. The second is sent to a freight brokerage in Memphis, where dispatchers depend on a carrier portal with no API and hardware-token authentication. The requirement reads "dispatchers stop re-keying load confirmations," the definition of done is a go-live date agreed with the operations lead, and the hardest item is often a permissions request waiting on the customer's security team.

The two jobs also feed each other. PostHog's engineering blog describes it in one image: FDEs build "the rough gravel road" to where the product needs to go, and software engineers turn it into "a paved superhighway" for the next ten customers. The full cycle runs from one customer's site back to every customer:

FDE is not yet a standardized title, so the line between the roles moves from company to company. Some use it for deeply technical deployment work, others for work closer to solutions engineering. The Pragmatic Engineer's reporting on OpenAI draws one practical boundary: solutions architects there tend to build MVPs offline with anonymized data, while FDEs write code directly on customer infrastructure using the customer's tooling. Where titles blur, the three questions from the top still sort the job: who the code is for, where it runs, and who signs off.

If the role you are weighing sits closer to solutions engineering, the sales engineer comparison shows where that line sits:

FDE vs Sales Engineer

Pre-sale demos or post-sale production code compared: pay, travel, the hand-off on one deal, and when to hire each.

Open the comparison

The answers show up most clearly in how each engineer spends the week.

What does a forward deployed engineer do all day that a software engineer does not?

A forward deployed engineer spends a large share of the week at the customer's site or on the customer's calls, and a software engineer spends little of it there. As of October 2026, postings that name a number usually put it between 25% and 50%:

• Our sample: of 102 FDE postings we collected on October 7, 2026, 52 state a percentage, ranging from 20% to 75% with a median of 40%.
• Palantir: about 25% of an FDE's time at customer locations, as reported by The Pragmatic Engineer.
• OpenAI: up to 50% travel.
• Anthropic: 25% to 50% for London, Munich, and Paris.

Software engineering postings at the same companies carry no travel line. Travel is one of six responsibilities that fill an FDE's week, and only one of them, the product feedback loop, overlaps with a product engineer's job:

The coding still happens, in the time left over. One Palantir FDE described the rhythm to The Pragmatic Engineer:

"Most weeks, I spend a couple of days working at the customer premises... Back in the office, I spend some time writing minor code changes, reviewing pull requests."

Put the two engineers side by side on an illustrative Tuesday in week three (our composite, not measured data):

By Friday both have shipped code. What happens to that code next is where the jobs split again.

Who owns the code, and what happens to it after the engagement?

An FDE usually writes deployment-specific code close to the customer's environment, and a software engineer usually writes generalized product code the vendor maintains. The boundary varies by company: some FDEs work directly in customer infrastructure, while others build custom applications on the vendor's platform.

Where the code lives in the customer's account, it runs against the customer's credentials and security policies. The postings name what gets built:

• Anthropic: "MCP servers, sub-agents, and agent skills that will be used in production workflows."
• OpenAI: the FDE owns "discovery, technical scoping, system design, build, and production rollout."

That raises a question a product engineer rarely has to ask: who runs this when the FDE leaves? If the honest answer is "only the vendor," the engagement has built a dependency. A clean handoff leaves the connector, its tests, and a named owner on the customer side.

The second output is the memo back to the product team. The Memphis connector stays in Memphis, but the pattern behind it, an agent acting inside a third-party portal with no API, travels back. The Pragmatic Engineer reports that until about 2016 Palantir had more FDEs than regular software engineers, and that after Foundry launched many moved into product engineering as the platform absorbed patterns they had built by hand.

Two jobs that trade code and people this closely invite the obvious question: does one pay more?

Which pays more, a forward deployed engineer or a software engineer?

As of October 2026, Levels.fyi shows U.S. forward deployed engineers at a median total compensation of $216,250, about 10% above the roughly $197,000 median for software engineers. The figures are self-reported totals including equity and bonus.

Sources: Levels.fyi self-reported data for the FDE and software engineer rows, Anthropic's posting for the London base, and the U.S. Bureau of Labor Statistics for the profession-wide wage.

Read the 10% gap with care. The comparison does not control for seniority, location, company, or submission mix. The FDE sample is smaller and skews to AI labs, Palantir, and Google, which pulls its median up. Both Levels.fyi medians also sit well above the BLS figure for the profession as a whole.

Pay is the visible difference. The one an FDE feels every week is a kind of system the product engineer never has to touch.

Which blocker do FDEs hit that software engineers rarely face?

The blocker that separates the two jobs most sharply is a workflow that runs through a web application the customer uses but does not own, with no API and a login tied to one person's machine. In Memphis, that is the carrier portal. A carrier owns the code, and every login runs through the carrier's SSO plus the hardware token on the dispatcher's desk. The product engineer never meets this system, because product tests run against mocks and the vendor's own services. The FDE has a go-live date that depends on an agent confirming loads inside it.

There are four ways in:

The first two routes work when the vendor can hold its own credentials: a service login, an API key, or a session a script can open alone. They scale and are testable. They stop where the session belongs to a person, because an SSO cookie, an MFA push, and a hardware token all live on the dispatcher's machine. Handing those credentials to the vendor would show up as a finding in the customer's next security review.

The last two routes work inside the person's own session. RPA reaches it through a per-seat install and scripts that follow the screen layout. Webfuse acts inside the user's active browser session, so the agent runs with the dispatcher's own SSO and token while the dispatcher can step in at any point.

Webfuse is our product, so this is the architecture we know first-hand. It fits user-present workflows that need the user's authenticated live session. For unattended jobs with service credentials, Playwright or a remote browser is usually the better option. The full architecture is covered in How to Connect an AI Agent to the Live Web.

Problems like the carrier portal are also the clearest guide to what an engineer has to learn when moving from one role to the other.

Which skills transfer between the two roles, and in which direction?

Engineers move in both directions, and the code skills carry over either way. PostHog's reading of the market lands on "5+ years of engineering or technical deployment experience" as the entry bar. What changes is the shape of the skills around that shared base:

• Software engineer to FDE: add breadth. SSO and role-based access in someone else's identity provider, cloud accounts the engineer does not administer, and eval sets built from the customer's real cases.
• FDE to software engineer: add depth. One system instead of six, and design for the tenth customer instead of the one in the room. Palantir's post-2016 shift shows this direction can work at scale.

Since the move works both ways, picking a first role is a question of fit more than of career rank.

Which career fits you better?

Choose forward deployment if you want the customer in the room, and software engineering if you want the product in the room. Four questions settle it faster than a job description:

The last question is the one most people skip. The best FDE work ends with a handoff and a memo, so the code you are proudest of is maintained by someone else. If that sounds like loss, the product side will suit you better. If discovering requirements in a shift-change meeting sounds more interesting than reading them in a ticket, forward deployment fits.

The bottom line

The two roles are halves of one loop. The FDE finds out what one customer needs and builds it where that customer works. The software engineer takes what keeps coming back from the field and turns it into product every customer gets.

Along the way, three things set the jobs apart:

• The work: an FDE spends 25% to 50% of the time with the customer and answers for a go-live date. A software engineer stays with one codebase and answers for a release.
• The code: an FDE's code stays with one customer and needs an owner there. A software engineer's code is maintained by the vendor for years.
• The hard part: an FDE meets systems the product team never sees, like a portal behind someone else's login with no API.

Pay sits close enough that it should not decide the choice, and engineers cross in both directions. Pick the week you want to have and the result you want to be judged on.

Both engineers in the Memphis example are doing real engineering. One is building the road for the next ten customers. The other is finding out, in a conference room in Memphis, where the road has to go.

Methodology and sources

The figures above come from public sources read in early October 2026. Two parts of the article, the Memphis example and the Tuesday table, are our own illustrations.

Levels.fyi medians move as submissions arrive, so the pay figures will drift from the ones above.