Forward Deployed Engineer: A Founder's Guide

A forward deployed engineer (FDE), also called a forward deployed software engineer, is a customer-facing software engineer who builds and deploys software inside a customer's own operational environment rather than from the vendor's office. The job is to make the product do real work in that specific environment: map the messy actual workflow, wire the software into the customer's data and systems, configure and tune it until the business numbers move, and carry what is learned back to the product team. Palantir made the role famous, and in 2026 nearly every serious enterprise AI company is hiring for it.

Here is why founders should care. In a Y Combinator interview, Varun Vummadi, co-founder and CEO of Giga (a Summer 2023 YC company whose AI support agents run for customers including DoorDash), was asked what the next few years look like for his company. He did not answer with a model or a feature. He answered with a staffing problem:

The biggest bottleneck of every single enterprise AI deployment, regardless of support or any automation that I want, this concept called forward deployed engineer, you need to have them bunch of them coming and sitting with the customers and configuring it.

That is a useful thing to hear from someone shipping support agents into some of the largest call volumes in the world. If you are building anything enterprises install rather than merely sign up for, this role is going to shape your headcount, your margins, and how fast you can add customers.

What a forward deployed engineer actually is

The definition is narrower than any engineer who happens to talk to customers. A forward deployed engineer develops and deploys software within or alongside a client organization's operational environment, combining software development and system integration with direct collaboration with the customer's own people, according to the Wikipedia entry on the role. The work spans requirements analysis, integration, application design, testing, deployment, and adapting the platform to that organization's data and infrastructure. Some FDEs stay with an implementation from the first conversation about an operational problem all the way to a running production system.

The Palantir origin. The title is closely associated with Palantir, which independent publications credit with pioneering or popularizing the model. An early published example appears in TechCrunch's June 2010 report on Palantir, which walks through a product demo with an employee identified as a forward deployed engineer. The company later used "forward deployed software engineer" for the engineers who worked directly with government and commercial customers. The distinction Palantir drew is the one that matters: these engineers were separate from the people building the generalized product, even though both groups wrote software.

The clearest current job description comes from OpenAI's forward deployed engineer posting, which describes the team as operating at the intersection of customer delivery and core platform development. The role owns discovery, technical scoping, system design, build, and production rollout alongside strategic customers, embeds closely with customer teams, contributes directly in the code when progress depends on it, and sends field feedback back into research and product. It is not just the labs: Stripe lists forward deployed engineering roles on its own careers site, and reporting in 2026 identified Anthropic and Google Cloud among the other companies staffing the function or something close to it.

Forward deployed engineer vs solutions engineer, and the roles it is not

A forward deployed engineer is not any engineer who happens to talk to customers. Three adjacent roles get confused with it:

• Solutions engineer. Supports the sale: demos, technical objections, scoping what is possible. Measured on pipeline and win rate, and usually hands the account off at signature.
• Customer success manager. Owns adoption and renewal of what already ships. Does not write production code.
• Support engineer. Closes tickets against the shipped product.

All three help the customer use what exists. An FDE builds what does not exist yet, for one customer, in production, and is measured on whether that customer's own number moves.

Why every enterprise AI deployment bottlenecks here

The model stopped being the hard part. Any founder can call a frontier model today for the price of a credit card, and the gap between the top models keeps narrowing for most tasks, which we covered in choosing the best LLM for your startup. What has not gotten cheap is making that model work on one company's actual mess: their policies, their legacy systems, their exceptions, their definition of a resolved ticket.

That work is bespoke by nature, and it does not shrink as you add customers. It multiplies. Which means the number of competent engineers you can put in the field becomes a hard cap on how many logos you can onboard, no matter how good your product demo is. This is the structural reason Vummadi points at the role rather than the technology, and why he closes with the plainest possible statement of intent: "the biggest bottleneck right now is forward deployed engineer and we're going to take it over."

It is also the reason the role has become a wedge for new companies rather than just a cost line for existing ones. In a Stanford CS153 talk on the AI-native company, the pattern described is founders who pick one painful workflow and "basically become the forward deploy engineer" for it. That is the same play behind running an AI-native company and the services-margin math in service as software: when the integration work is the hard part, doing the work yourself is a legitimate way in.

The last mile is configuration, not code

Vummadi's description of the field work is less glamorous than the title suggests. He argues that for almost any AI agent company, the product reduces to a set of policies written as a markdown file, and the whole discipline is iterating that file until a business number moves. For support, the number is resolution rate or customer satisfaction. He describes deployments that start around 30 to 40 percent resolution and the entire job being how you climb from there toward 90 percent, and says the same fundamentals carry over to compliance and IT service management.

So the bottleneck is not a technology gap. The customer is not asking for a new model. They are asking questions like how do I get from 40 percent to 60 percent, or can you spin up a new dashboard for me. Each answer is a small, high-context change to instructions, integrations, and evaluation, made by someone who understands both the product and that customer's operation.

The scale of what is on the table explains the patience for this work. Vummadi describes the traditional support path, where a caller hits an interactive voice response system or a chatbot before reaching a human, as deflecting somewhere in the range of 10 to 15 percent, while a human-like AI agent gets to roughly 60 to 70 percent, with 90 to 95 percent the goal for the best customers. Those are the kinds of deltas that justify sending engineers to sit with a customer for months.

If you want the deeper version of the configuration problem, it is really a knowledge problem: the policies an agent follows are your customer's institutional know-how written down in a form a machine can execute. We covered that in AI knowledge management, and it is why the FDE role is so hard to hand to a generalist. Most of the difficulty is in knowing what the rules should say.

What the role actually costs you per logo

Price this honestly before you build a motion around it, because it is one of the most expensive functions a young company can carry.

• Senior engineering salary, in a customer-facing seat. You need someone who can write production code and hold a room with an operations lead. That person is not cheap, and they are not billable in the way a consultant is.
• Travel and physical presence. OpenAI's posting for the role, as published in 2026, states that travel up to 50 percent is required. Sitting with the customer is a literal instruction, and it prices like one.
• Time to value measured in months, not days. Vummadi describes the DoorDash win as a three-month pilot: "we piloted for like 3 months. We never went down, and all the metrics were good." That is the bar, and it is a quarter of a senior engineer's year for one logo.
• A cost of goods sold line that looks like services. Deployment labor sits in COGS, not sales and marketing, which is exactly the margin trap we described in service as software. Traditional services firms top out around 30 percent margins. If every new customer needs the same amount of field engineering as the last one, you are running a consultancy with a software logo.

The counterweight is that this cost buys something an incumbent's sales team cannot. Giga was a team of eight when it won DoorDash against a much larger and better-funded competitor, and Vummadi's read on why: there is "a lot of arbitrage of actually building a great product rather than a sales team." He also credits the YC network for the introduction that got them in the room, and notes DoorDash is itself a YC company, which is a reminder that trust from a warm intro plus a clean pilot beats brand at this stage. On the pricing side, if deployment labor is real, it belongs in how you charge, which we worked through in how to price an AI product.

What the role pays, and who is actually good at it

You cannot write the requisition without a view on both. On pay, check the live numbers rather than trusting any article, including this one: Levels.fyi and Indeed both track the title, and the reported ranges move fast and vary a lot by company tier. What matters for planning is the shape, and the shape is unambiguous: this is priced as a senior individual-contributor engineering role, not as a support or consulting role, and at the frontier labs a large share of the package is equity. If you budget it as a post-sales hire, you will not close the candidates you want.

On who is good at it, the profile is genuinely uncommon, which is the real reason the bottleneck exists. You need someone who can ship production code and sit in a room with a customer's operations lead without a salesperson translating. Two paths tend to produce that person: a product engineer who likes customers more than most engineers do, and a strong solutions engineer or consultant who can actually write and own code rather than just configure. Vummadi's own hiring filter is worth stealing: he looks for what he calls spikiness, some extraordinary ability that puts a candidate in a very small percentile, rather than a uniformly good record.

Be straight with candidates about the tradeoff, because it is the thing the role's critics get right. The work is high-context, high-travel, and much of what you build is scoped to one account rather than to the product everyone sees. That is a real cost to a career built on shipping widely used systems. The compensating upside is unusual: FDEs see how a large organization actually operates, and Business Insider has reported on how Palantir's version of the role churns out startup founders.

When your startup actually needs a forward deployed engineer

Not every company should have this role, and hiring it early because it sounds impressive is a good way to build a services business by accident. First Round Review's guide to hiring a forward deployed engineer frames the decision as a diagnostic with three conditions: you have landed or are going after big fish, you are not prescriptive about how you want customers to use your product, and you do not have a uniform ideal customer profile. It also warns against the most common failure mode, which is shoving an FDE into an ordinary engineering or post-sales role.

Read those three conditions as a test of whether your last mile is genuinely bespoke. If your product installs in an afternoon and every customer uses it the same way, you need better onboarding, not field engineers. If your top ten deals each require different integrations and a different definition of success, you need FDEs, and you should say so out loud in your plan rather than letting the work leak into your engineering team's sprints.

The other half of the decision is which customers deserve it, which is really the sales-motion question. Field engineering only pays back on contracts large enough to absorb it, which pushes you toward a top-down motion and away from self-serve. We laid out that tradeoff in top-down versus bottom-up sales. Note also that if you do not have a uniform profile yet, the fix may be upstream: sharpening your ideal customer profile will reduce how much bespoke work you sign up for in the first place.

What an AI forward deployed engineer can absorb

The bottleneck is now a product category of its own. Vummadi's answer to the constraint is to automate it: "We're trying to build an AI forward deployed engineer." He describes it joining the customer's Slack, sitting in on video calls, taking the notes, and then making the configuration changes itself, so a request to lift a resolution rate or add a dashboard does not have to queue behind a human's calendar.

The idea is less exotic than it sounds, because the same argument is showing up elsewhere. A Y Combinator talk on dynamic software interfaces makes the case that coding agents are now good enough for users to become their own forward deployed engineers, customizing the software they consume rather than accepting whatever shipped. We unpacked that shift in generative UI. Both point at the same economics: customization used to be a service you could only afford to give your largest accounts, and it is becoming something the product does by default.

Giga's own team shape is the evidence that this works. Asked how many engineers the company would need without coding agents, Vummadi's answer was "there should be at least like six to seven times more compared to now," and his reason is not payroll. It is that handoffs destroy context: "It's better without context switching. It's better for you to own the thing and build the entire thing rather than having like a lot of people working on it."

Be precise about what actually automates, though. The mechanical middle of the job (translating a request into a policy change, running the tuning loop, generating a view of the data) is a good fit for agents. Deciding which workflow is worth automating, earning trust with the customer's operators, and owning the consequences of a change in production is still human work. The realistic target is a small field team with agent leverage, not no field team. If you are asking the broader version of this question about your own engineers, we answered it in will AI replace software engineers.

The access problem nobody scopes

One part of this role gets systematically under-designed, and it is the part that will end up on your security questionnaire. A forward deployed engineer, human or agent, holds credentials inside someone else's production environment. They see real customer data, they change behavior that affects real users, and they often work faster than any change-management process the customer has.

Scope it deliberately before the first deployment:

• Least privilege, on the customer's identity system. Your engineer should work through accounts the customer provisions and can revoke, scoped to the systems the project needs, not a shared admin credential passed around your field team.
• An audit trail for configuration, not just code. If policies are the product, then policy changes need version history, an author, and a diff. Someone edited the markdown during a call is not an answer that survives an audit.
• Approval and rollback for anything an agent changes. The moment an AI FDE can edit production behavior on its own, you need a review gate for consequential changes, a clear kill switch, and a one-step revert. We covered how to stage that authority in proactive AI.
• Explicit data boundaries. Say in writing where the customer's data lives, how long you keep transcripts and logs, and whether anything from their environment trains a shared model. Enterprise buyers will ask, and a vague answer costs you the deal.

Getting this right wins deals, not just audits. When a small team asks a large enterprise for production access, the credible security story is often what makes the pilot possible at all.

What to do this week

1. Write down your real last mile. For your three most recent deals, list what a human on your side had to do after the contract was signed before the customer got value. That list is your FDE job description, whether or not you have the title.
2. Put a number on it. Estimate engineer-days per new logo and multiply by your loaded cost. Compare it to first-year contract value. If it eats more than a fifth of the deal, you have a margin problem to design out, not to staff around.
3. Decide if the work is bespoke or just unautomated. Run the three-condition test: big customers, non-prescriptive usage, no uniform profile. If you fail all three, fix onboarding instead of hiring.
4. Pick one repeated field task and automate it this week. The status report, the weekly tuning pass, the dashboard request. Start where the work is mechanical and the blast radius is small.
5. Interview for the real job. Giga's screen is a good template: "We ask them to write code and then remove access to the tool and ask them to change the code without AI." Their point is that the person has to understand the system, not just prompt it. Pair that with a problem-solving interview rather than a puzzle.
6. Write the access policy before the first deployment. Customer-provisioned accounts, scoped permissions, configuration audit trail, rollback path, data retention in writing.

The pattern underneath all of this is the one we keep coming back to across the AI for startups pillar: the model is a commodity, and the durable work is in the last mile between a capable model and one company's messy reality. If you want the full operating system for running a startup this way, from field deployment to internal automation, that is what we teach in AI Operating System for Startups.

Sources

• Why Two IIT Engineers Turned Down $550K Jobs To Build A Startup (Y Combinator), the interview with Giga co-founder and CEO Varun Vummadi that this article distills, including the forward-deployed-engineer bottleneck, the deployment mechanics, and the DoorDash pilot.
• Forward Deployed Engineer (Wikipedia), for the definition and for Palantir's origination of the role. The underlying primary sources are cited directly above: TechCrunch's June 2010 Palantir report for the early use of the title, and Stripe's own careers listing for adoption outside the labs.
• Forward Deployed Engineer (FDE), San Francisco (OpenAI careers), the primary source for the role's scope as published in 2026 and the 50 percent travel requirement. Note this is a live job requisition and may move once the role is filled.
• So You Want to Hire a Forward Deployed Engineer (First Round Review), for the three-condition hiring diagnostic and the warning against folding the role into engineering or post-sales.
• Palantir's forward deployed engineer role churns out startup founders (Business Insider), on the career upside of the role. Current pay ranges: Levels.fyi and Indeed.
• Company and people background: Giga on Y Combinator for the Summer 2023 batch, and TechCrunch on Giga ML's early on-premise LLM product for the co-founder pair, Varun Vummadi and Esha Dinne. Vummadi credits two people at YC: Harj Taggar, a Managing Partner, for the bet on the batch, and Garry Tan, YC's President and CEO, for the DoorDash introduction.
• Stanford CS153: The AI Native Company (Stanford Online), on founders winning a wedge by becoming the forward deployed engineer for one painful workflow.
• Dynamic Software Interfaces (Y Combinator), on coding agents letting users become their own forward deployed engineers.
• How to Build an AI-Native Services Company (Y Combinator), for the services-margin math and the cost-of-goods-sold framing applied to deployment labor.