A forward deployed engineer (FDE) is a software engineer who works directly with the people using a product, works out what they need, and ships it into production with little direction. Production means the live system that real users depend on, not a demo or a test copy.
Three things have to be true for the title to mean anything:
- Direct contact. The engineer talks to users or customer stakeholders in person or on calls, rather than reading a ticket someone else wrote after talking to them.
- Working out what to build. The problem arrives unscoped. Part of the job is deciding what the real problem is.
- Shipping. The engineer writes the code and gets it live.
Take one away and you have a different job. Contact and diagnosis without shipping is closer to a consultant or product manager. Shipping without contact is a software engineer working through a backlog, which is valuable work, but it isn’t this role. Contact and demos without production code is usually a solutions engineer.
This guide is written for CTOs and founders deciding whether they need one, including founders who don’t write code.
Where the role came from
The role began at Palantir, the data analytics company. The Pragmatic Engineer dates it to the early 2010s, when these engineers were known internally as Deltas. First Round Review places the origin nearly two decades before its 2026 article, so accounts of the exact date differ.
The reason for the role is better agreed than the date. Early Palantir rarely defined its product in advance, according to former FDE Shilpa Balaji in First Round Review, so engineers had to work out what each customer needed while sitting with them. The Pragmatic Engineer reports that until around 2016 Palantir employed more FDEs than standard software engineers, and that many moved into core product work after its Foundry platform launched.
The title spread widely with AI. PostHog names OpenAI, Anthropic, Databricks and Ramp among the companies that hire or have hired for it. Insight Partners explains the demand this way: most AI products don’t work out of the box for a specific customer’s use case, so someone has to finish the job with real data.
Published demand figures point the same way but disagree on size. First Round cites the Financial Times for a rise of about 800% in monthly job listings from January to September 2025. Paraform, a recruiting company, reports 350% growth on its own data from Q1 2025 to Q1 2026, and also reports Bloomberry’s figure of 1,165% year over year. They measure different things, and none of them tells you whether you need one.
Two versions of the job
Most writing about FDEs describes one version of the role, and many startup readers need the other.
The product company version. The engineer works for a company that sells software, and embeds with that company’s customers to make the software work for them. What they learn goes back to the core product team. This is the Palantir and OpenAI pattern.
The startup version. The engineer works inside a young company and stays close to its own users. They might get the product live at the first few demanding customers, or they might work out and ship what the product should become. Insight’s panel argues founders should consider this approach even at seed stage, and one panelist suggested treating it as the main way a new B2B company does engineering. Paraform says seed to Series A companies make up 59% of the companies hiring FDEs on its platform.
The skills are the same in both. The difference is who the users are and how far the engineer sits from the decision makers. In a startup, that distance is often zero.
There is also a separate question of how you employ the person: a direct hire, a contractor or a monthly placement. The title says nothing about that, and how to hire a forward deployed engineer compares the three.
What an FDE does day to day
No two weeks look alike, and the published accounts show how much the mix varies.
The Pragmatic Engineer describes a typical week as three kinds of work: customer work, improving the platform, and internal tasks such as meetings. It cites two Palantir FDEs writing in 2019. One spent a couple of days a week at customer sites debugging, deploying and configuring software, then made code changes back at the office. The other’s work moved month to month between building and scoping with customers.
The balance can tilt much further toward code. Jake Stauch, CEO of Serval, told First Round that his FDEs spend about 20% of their time with customers, and that they have shipped more than 60 third-party integrations. In Insight’s day-in-the-life panel, an FDE at Wonderful described one day spent coding and fixing bugs, another on deployment at the customer, and another with the product team.
In practice, the work tends to include:
- Sitting in on customer calls and asking what the user was trying to do when something went wrong
- Connecting the product to a customer’s data and systems, then fixing what breaks on real data
- Building a rough version in days and putting it in front of users
- Deciding what not to build, and explaining why to whoever asked for it
- Writing the tests, monitoring and documentation that keep the work running after it ships
- Turning something built for one customer into something that works for the next one
That last item is where the role can go wrong. Stauch warns that FDEs can build features that don’t generalize, which is why product sense matters as much as coding.
What the role isn’t
Tiffany Siu, First Round’s head of talent and a former Palantir recruiter, says founders often ask for an FDE when they really need a software engineer, an implementations lead or a customer success manager. She suggests asking what triggered the opening, who does the work today, what the person’s day looks like, and how success will be measured. If success means closing deals or running demos, the role is closer to sales.
FDEs compared with solutions engineers and consultants
These three roles get mixed up because all of them talk to customers and all of them have technical skills.
| Forward deployed engineer | Solutions engineer | Consultant | |
|---|---|---|---|
| Main job | Build and ship what users need | Show that the product can solve the problem | Diagnose the problem, recommend a fix or deliver a set scope |
| When | Usually after the sale, and ongoing | Mostly before the sale | For the length of the contract |
| Production code | Yes | Rarely: demos and proofs of concept | Usually not |
| Problem | Unscoped | Defined by the deal | Defined by the contract |
| Judged by | Whether it works for real users | Deals won or renewals | Whether the scope was delivered |
The table draws on KORE1’s role comparison, The Pragmatic Engineer and Insight Partners. KORE1, a recruiting firm, notes that these titles get conflated even inside the companies posting them, and PostHog says some FDE roles look more like technical consulting or sales engineering. Read the job, not the title.
The Pragmatic Engineer makes the consulting difference simple: consultants tend to make one-off recommendations, while FDEs work with customers over the long term. Insight’s panel adds that consultants deliver a defined scope and leave, while FDEs take an unscoped problem and build the last-mile solution, meaning the final stretch of work that makes a product function in a particular customer’s setup.
For a closer look, read forward deployed engineer vs solutions engineer. If your question is really about contracts and who gives direction, read forward deployed engineer vs staff augmentation, which also covers why “owns the outcome” means different things in different offers.
Does an FDE have to be on-site?
No, but they do have to be close to users, and being remote makes that harder.
On-site work is the classic form of the role. Balaji told First Round about spending weeks at a customer’s factory in a small German town, and argues that extended time with a customer surfaces needs a 30-minute discovery call would miss. PostHog says typical FDEs travel 20% to 50% of the time, though some do virtual visits. PostHog’s own first FDE is fully remote and works asynchronously, and the company treats that as an experiment. So the remote version exists, but there’s less published experience behind it.
Being on-site isn’t enough by itself either. Rocketlane’s CEO described a bad day on Insight’s panel as traveling to a customer’s site and then getting blocked on access. What matters is access: to users, to systems and to the person who can make a decision.
How to stay close to users remotely
This is practical advice rather than research, and it works the same for any remote engineer in this role.
- Give direct access to users. Put the engineer on customer calls, and give them a named contact at each important customer. Don’t relay feedback through a third person.
- Watch people work. Ask a user to share their screen and do the task from start to finish, narrating as they go. This is the closest remote substitute for sitting beside them, and it shows the workarounds nobody mentions on a call.
- Share the raw signal. Give the engineer support tickets, usage analytics, session recordings and error logs directly, not a summary of them.
- Sort out system access before day one. Waiting two weeks for credentials is the remote version of being blocked at the door.
- Protect shared hours. A question answered the same day keeps work moving. Agree a daily overlap window with you and, where possible, with your users.
- Keep the loop short. Ship something small, ask the user to try it, and talk to them again the next day.
- Visit when it pays. A short trip suits a hard go-live (the moment a customer starts using the product for real), a stuck relationship, or a problem nobody can explain from a distance.
Where remote falls short
Some work needs someone in the room. That includes physical settings such as factories, systems on locked networks that outsiders can’t reach, and customers who expect a person on site as part of the deal. If that describes your main customers, budget for regular travel or look for someone local.
How to tell whether you need one
Most of the need comes down to two situations: customer go-lives are stalling, or nobody is close enough to users to work out what to build. When do you need a forward deployed engineer walks through the signs of each, along with the cases where you don’t need one, such as a self-serve product with a working growth playbook.
First Round’s interviewees add two useful filters. James Honsa, who led the equivalent team at Ironclad, describes the role as a way of selling to large customers, and not a fit if you expect a freemium model. Balaji warns that a founder with a fixed product vision will likely find an FDE a poor fit, because the role depends on letting what users need shape the product.
Cost is the other filter. The range is wide, because it depends on location and on the route you take. Forward deployed engineer cost compares the full cost of each route using sourced market figures.
Read next
- When do you need a forward deployed engineer?
- How to hire a forward deployed engineer
- What a forward deployed engineer costs
- Forward deployed engineer vs staff augmentation
- Forward deployed engineer vs solutions engineer
How epicX fits
epicX places forward deployed engineers with startups and scale-ups, from $5K a month. Engineers are in Pakistan and South Africa and work remotely by default, with at least 4 hours of daily overlap with you and short on-site visits if you sponsor them. You direct the engineer and own the result, and epicX doesn’t review the work. If that model suits you, see how hiring a forward deployed engineer through epicX works. A founder takes every first call.