What is FDE ops?

FDE ops is the operational discipline of deploying, hosting, vaulting, versioning, and handing off customer-specific code, so the work a forward deployed engineer ships for one customer keeps running after the deal closes, independent of the engineer who wrote it. It is software for FDEs and for the people who run them. It is not a project tracker, not an AI coding assistant, and not the product roadmap wearing a customer name.

That is the definition. The rest of this article exists because the noun is new, the work is not, and a lot of teams are currently shopping the wrong aisle for it.

Why the noun had to be invented

Forward deployed engineering is no longer a Palantir idiosyncrasy. Business Insider reported that Indeed's index of forward deployed engineer postings sat 543 percent above its January 2025 baseline by April 2025, and 5,230 percent above that same baseline by April 2026, roughly 729 percent growth year over year. Those figures are indexed values, not raw job counts, which is the correction Insider itself issued, and they are still the cleanest public picture of how fast the role moved. Bloomberry's analysis of 1,000 FDE postings independently counted 1,165 percent year-over-year growth through October 2025, and credited Palantir with coining the original title. Anthropic, OpenAI, Palantir, Stripe, and Google Cloud are all hiring for the role by name.

The cause is not a branding cycle. Enterprises spent two years buying models and then discovered that buying AI and benefiting from AI are different events. MIT's Project NANDA, as reported by Fortune, found that 95 percent of enterprise generative AI pilots produced no measurable profit and loss impact, with the roughly 5 percent that succeeded running systems adapted to actual workflows rather than generic tools dropped onto them. S&P Global Market Intelligence, as reported by CIO Dive, found the share of companies abandoning most of their AI initiatives jumped from 17 percent to 42 percent in a single year, in a survey of more than 1,000 respondents across North America and Europe; the average organization scrapped 46 percent of AI proofs of concept before they reached production. Gartner forecasts that more than 40 percent of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, or inadequate risk controls. Someone has to close that gap customer by customer, inside each customer's systems, data, and security constraints. That someone is a forward deployed engineer.

Here is the part the hiring wave did not come with a plan for. Every one of those FDE hires produces a new class of asset, at a volume most companies have never managed: customer-specific code. Integrations, scripts, glue services, last-mile automations. Each one belongs to one customer. Each one holds real credentials. Each one runs somewhere. Each one is known intimately by exactly one person. Multiply a team of five FDEs by a year of closed deals and you get hundreds of small running systems, none of which look like the core product, none of which the product org's pipelines were built to carry, and all of which become a customer incident the day their author is on a plane, on vacation, or gone.

Palantir, the company that split engineering into Deltas and Devs, spent years building internal machinery around that output. Palantir's own language is useful here: a core software engineer focuses on "one capability, many customers"; a forward deployed engineer focuses on "one customer, many capabilities." Many capabilities, per customer, times a book of customers, is an estate. Nabeel Qureshi, an eight-year Palantir veteran, describes in Reflections on Palantir how FDEs typically sat onsite three to four days a week so that what they learned inside a customer's processes could flow back into software the product team would later generalize. That loop only compounds if the field's output is visible, retained, and reusable. The companies copying the role in 2026 mostly copied the headcount and not the machinery. They have an engineer, a customer with a deadline, and a company cloud account tuned for the core product. So the work goes where friction is lowest: a script on a laptop, a credential in a personal password manager, a cron job on a forgotten VM, a deploy that only one person knows how to repeat.

That pattern has a name now, because it needed one. FDE ops.

The five verbs: deploy, host, vault, version, hand off

FDE ops is not a vibe and it is not a meeting. It is five verbs, and the category is whatever makes each of them a decision rather than a per-engineer improvisation. We judge platforms on these verbs in the FDE ops platform guide. This article is the definition those platforms exist to serve.

Deploy. Working code becomes running code, on a sanctioned path, in minutes. The FDE promise to a customer is speed: we heard the requirement in the room and we can ship it. If the sanctioned path is a ticket into the product organization's release train, the sanctioned path is slower than the customer's patience, engineers route around it, and you learn about your real deploy path during an incident. Deploy, in FDE ops, means a lane that exists for customer-specific work, separate from the core product pipeline, without asking platform engineering to stand up infrastructure per customer. The unit of that work, when it is done on a purpose-built platform, is a customer-specific integration: one build, one customer, no change to the product that every other customer runs.

Host. The code runs somewhere owned and monitored, never on the laptop that built it, never on a VM whose existence depends on one person's memory. Hosting is the unglamorous half of the FDE job, the part that turns a demo into a system. Teams that skip it treat POCs as throwaways and then discover, on the morning the deal closes, that the throwaway is now production. Why AI POCs fail is, more often than the postmortems admit, a hosting story wearing a model story.

Vault. Customer credentials go into custody where engineers reference them in code but cannot read the values. This is the verb that converts a security review from a per-engineer trust exercise into an architecture answer. The customer's security team is going to ask where their API keys sit and who can see them. "In our FDE's env file" does not pass. "In an AES-256 vault with zero-access custody" does. Vault is also the verb most teams fake with a password manager and a policy, which is how credentials sprawl across personal accounts until the first departure makes the sprawl a disclosure conversation.

Version. Every customer build retains its history, so "what changed" has an answer at 6 p.m. on a Friday. Versioning in FDE ops is not "we use git." Plenty of teams use git and still cannot say which copy is running at the customer, because the running copy and the repo copy diverged the night someone hotfix-edited production from a laptop. Version means the running artifact has a lineage the organization owns: what shipped, when, by whom, and what to roll back to.

Hand off. Transferring an account's work is an operation, not a two-week pairing marathon that never happens before the departure date. Handoff, done honestly, is a same-org reassignment of the running work, a note for the successor, and retained versions. It is not a zip file, not a wiki page, and not a package you throw over a wall. The full emergency procedure lives in the playbook for when an FDE leaves. The architectural fact underneath that playbook is this verb. If handoff is not a property of how the work is stored, it will never be a property of how the team behaves.

Five verbs. That is the whole job. Everything else in the FDE org (reporting lines, pods, rituals, metrics, the first ninety days) is how you run the people. That material already has a home in how to run an FDE team, and this article will not rewrite it. FDE ops is how you run the artifacts those people produce.

What FDE ops is not: project trackers and AI coding assistants

Two categories keep getting invited into this conversation, and both are useful, and neither is FDE ops.

Project trackers organize humans. Jira, Linear, Asana, Notion databases, the spreadsheet of names next to accounts: these tell you who is supposed to be working on the Acme integration this week. They cannot tell you which version of it is running, where it is hosted, who can read the credential it uses, or what happens if that person resigns on Thursday. A tracker can be the window onto the work. It cannot be the floor under it. Companies that buy a dashboard and believe they bought an ops layer find out during the first security review or the first departure, which are the two worst possible moments for the discovery. The management-shaped version of this confusion (estate visibility mistaken for a ticket board) is the subject of software to manage FDE teams. The short version for this definition: if a tool's pitch is visibility without deploy, host, vault, version, or hand off underneath it, it is a window, not a floor.

AI coding assistants speed up writing. Editor copilots, in-product coding help, the whole generation of tools that draft the first version of a script from a prompt: these make an FDE faster at producing customer-specific code. That is a real gift, and it is why a serious FDE ops platform will ship coding help as a feature. It is also why coding help cannot be the product. Faster writing multiplies the ops problem. More customer builds, produced sooner, all needing the same hosting, custody, versioning, and handoff the moment they work. Treating the assistant as the platform is how a team gets to a hundred undocumented running scripts in a quarter and calls it velocity.

There is a third near-miss worth naming so it does not sneak back in. Docs and wikis record the estate; they do not operate it. A runbook that describes the script on the laptop is still a laptop. Tribal knowledge capture matters, and we wrote the guide to it, but capture without a system of record is a memoir. FDE ops is the system of record that makes capture a byproduct of shipping rather than a homework assignment.

FDE ops platform, FDE deployment platform, software for FDEs

The searches that land on this page are not all the same query, and pretending they are is how a category stays muddy. Three phrases keep showing up. They point at one thing.

FDE ops platform. This is the category name. An FDE ops platform is software that carries the five verbs for customer-specific code: it deploys the build, hosts it, vaults the credentials, versions the artifact, and makes handoff an operation. Evaluated that way, the market currently splits into a purpose-built shape and a pile of general-purpose infrastructure that covers one or two verbs brilliantly and leaves the rest as an internal project. The comparison lives in best FDE ops platforms. If you remember one test: does the tool know which customer every piece of running code belongs to, as a first-class fact? If it does not, you will rebuild that fact in naming conventions, wikis, and memory, which is to say you will not have it.

FDE deployment platform. This is the same category, named from the verb teams feel first. People search "what is an FDE deployment platform" when an engineer has just been asked to ship a customer integration by Friday and the company's answer is still "open a ticket with platform." An FDE deployment platform is the sanctioned path from working code to running code for last-mile, one-customer work, with the other four verbs coming along because a deploy that does not vault, version, or survive a handoff is a demo. The phrase is useful. It is also incomplete if it stops at deploy. Deploy without custody is how you get fast and unsafe. Custody without deploy is how you get safe and unused. The platform is the combination.

Software for FDEs. This is the broadest phrase, and the one most likely to lead a buyer into the wrong aisle. Software for FDEs could mean the editor they write in, the tracker they resent, the CRM they do not want, the assistant that drafts their scripts, or the platform that keeps their customer builds alive. Only the last of those is FDE ops. The rest can sit around it. Sales engineers and forward deployed engineers will evaluate that last piece by putting a real customer build on it this week, because that is the only evaluation that matters: did minutes-to-deploy change what they can promise in the room?

If you searched any of those three phrases, you were looking for this definition. The noun is FDE ops. The platform is whatever makes the five verbs true. The software for FDEs that belongs in this sentence is the ops layer, not the adjacent tools that organize or accelerate the people.

What is an FDE deployment platform, in concrete terms?

Strip the category language and look at the unit of work.

On a purpose-built FDE deployment platform, the unit is a bridge: a serverless function that connects your product to one customer's systems. That one-customer scoping is the whole idea. Because the platform knows which customer every piece of code belongs to, the questions your team actually asks (what do we run for this customer, who owns it, what version is live, where do the credentials sit) organize themselves. The code is internally versioned JavaScript, running in a Node vm. It is not a per-bridge app-platform project, and it is not a chance to smuggle a new language runtime into the estate. Python and Go are not on the menu, on purpose. The point is a constrained, inspectable, one-customer function, not a miniature product org per account.

Walk a build through the verbs on that shape. An FDE writes the bridge, deploys it in minutes, and does not file an infrastructure ticket or change the core product. The platform hosts it. Customer credentials go into an AES-256 vault with zero-access custody, so the engineer references secrets in code and never sees the values. Every version is retained and owned by the organization. When the engineer changes seats, handoff is a same-org reassignment plus a note plus those retained versions. The customer does not notice. The successor does not rebuild.

That is what "FDE deployment platform" means when the words are being used honestly. Plenty of other software can host a function or store a secret. The category starts when all five verbs are true for work that is scoped to one customer, owned by the org, and fast enough that FDEs will actually use it instead of their laptops.

What the job looks like when the verbs are missing

The failure mode is so consistent that teams who have lived it can recite it before you finish the question.

At one FDE and three customers, personal artifacts work. The engineer remembers what runs where. The password manager is theirs. The wiki page is more or less current. Nobody calls this FDE ops because nothing has caught fire.

At five FDEs and forty customers, four things happen, usually in this order:

Nobody can enumerate the estate. Ask what is running at which customer and the answer is an archaeology project across laptops, repos, cloud accounts, and memories. The weekly review that should take thirty minutes takes three hours of Slack archaeology, or it does not happen. RAND's study of AI project failure, built on interviews with 65 experienced practitioners, found the root causes overwhelmingly organizational rather than technical, and its list includes underinvestment in the infrastructure to deploy completed work. An unenumerable estate is that underinvestment, made visible.

Credentials sprawl. Customer API keys and database passwords live wherever the engineer who received them put them. Every new hire multiplies the surface. Enterprise security teams increasingly ask vendors exactly where their credentials sit, and they are no longer satisfied with a policy that says "use the vault" while the vault is optional. AI transformation keeps getting described as a governance problem; the version of governance that can answer a credential question is a vault, not a committee.

Versions become folklore. When a customer build breaks, "what changed" has no authoritative answer, because the running copy and the repo copy diverged months ago. The FDE who remembers the 6 p.m. hotfix is the version control system. That works until it does not.

Departures become incidents. The engineer who built a customer's integration leaves, and the integration becomes an unowned production system with no documentation, no access path, and a customer on the other end. This is not a talent problem and it is not an HR problem. It is what happens when a new class of work arrives before the operational layer for it exists.

The labor-market backdrop makes all four worse. The Bureau of Labor Statistics puts 2024 median pay for software developers, quality assurance analysts, and testers at $131,450, with employment in that group projected to grow 15 percent from 2024 to 2034, much faster than average. FDE pay sits above that already-expensive median: Indeed's range, per Business Insider, runs about $170,000 to over $200,000, and Bloomberry's median from disclosed salary ranges is $173,816. You are concentrating production systems for paying customers in the heads of people the market is actively bidding up. That is not a reason to panic-buy tooling. It is a reason not to treat the ops layer as optional.

How to know you need the noun, not a synonym

A few diagnostic questions, answerable this week:

If you asked, this afternoon, for a list of every customer-specific build currently running, would the list come from a screen or from a tour of laptops?

If a customer's security team asked where their credentials live and who can read them, would the answer be an architecture or a promise?

If the FDE who owns your largest account resigned on Thursday, would handoff be a reassignment or a rebuild? Time it honestly. If the honest number is more than a day, the account is a liability wearing a success story.

If an FDE can ship a customer fix faster from a laptop than through the sanctioned path, which path is actually sanctioned?

If the answers make you uncomfortable, you do not have a documentation problem and you do not have a staffing problem. You have an FDE ops problem. Staffing still matters, and how to staff an FDE team is the companion for the people side. The artifacts still need a platform even if the roster is perfect.

Archway, honestly

Archway is the purpose-built FDE ops platform, which also means it is an FDE deployment platform, which also means it is software for FDEs in the only sense this article is willing to defend. It was built for the five verbs, not adapted to them.

Bridges deploy in minutes with no core-product change. Hosting is the platform's job. Credentials sit in an AES-256 vault with zero-access custody. Every version is owned by the org. Moving an account is a reassignment of org-owned bridges plus a note, not a package and not a rebuild. There is AI-powered coding help in the editor; treat it as a welcome feature, because the product is the ops layer underneath it. The sidebar is not a CRM. Handoff is a property of how bridges are stored, not a separately named module.

Pricing is two bridges free, then $45 per bridge per month. The free tier is the point for a first evaluation: put a real customer build on it this week and see whether minutes-to-deploy changes what you say yes to. The business case is the same three numbers finance already values (deals unblocked, risk retired, roadmap not consumed by customer-of-the-week work) and it does not require you to pretend a platform is a strategy.

What Archway is not: a way to skip running the team. Reporting lines, pods, qualification gates with sales, estate-review rituals, and the first ninety days are operating problems, documented in how to run an FDE team. A platform will not invent those for you. What it will do is make the rituals cheap, because assembling the estate list stops being the meeting. Leaders who want the management-software view (visibility, custody, handoff, utilization as a leadership problem rather than a runtime problem) should read software to manage FDE teams, which is a different list on purpose.

The honest close is the same sentence we use for the category: speed for the people who ship, custody and control for the company that keeps the customer. FDE ops is that sentence, turned into infrastructure. If you have been searching for the noun, you can stop. This is it.

Quick answers

What does FDE ops stand for? Forward deployed engineering operations: the discipline of deploying, hosting, vaulting, versioning, and handing off customer-specific code.

What is an FDE ops platform? Software that carries those five verbs for one-customer builds, with the customer as a first-class fact rather than a naming convention.

What is an FDE deployment platform? The same category, named from the first verb teams feel. A real one also vaults, versions, hosts, and hands off; a deploy-only runtime is compute, not ops.

Is FDE ops a project management tool? No. Trackers organize people. FDE ops operates artifacts. You may want both. They are not substitutes.

Is FDE ops an AI coding assistant? No. Assistants draft code faster. FDE ops keeps the resulting customer builds alive, safe, and transferable. Coding help can be a feature of an FDE ops platform. It is not the product.

What software do FDEs actually need? A sanctioned path for customer-specific code that is faster than a laptop. Adjacent tools (editors, trackers, chat, the core product's cloud) can stay. The missing piece is almost always the ops layer.

Does FDE ops replace the FDE? No. The role exists because customer environments are specific. The ops layer exists because that specificity produces an estate. The FDE page is for the people in the seat. This page is for the discipline around the seat.

Sources and notes

• Business Insider (Cadie Thompson and Lakshmi Varanasi, May 2026): Indeed index of forward deployed engineer postings (543 percent above January 2025 by April 2025; 5,230 percent above that baseline by April 2026, roughly 729 percent year over year), named hiring companies, and the Indeed pay range of about $170,000 to over $200,000. Figures are indexed values, not raw job counts. https://www.businessinsider.com/forward-deployed-engineer-jobs-in-demand-2026-5

• Bloomberry, "What I learned analyzing 1K forward deployed engineer jobs" (updated January 25, 2026): 1,165 percent year-over-year growth in FDE postings from an analysis of 1,000 postings; Palantir credited with coining the title; median $173,816 from disclosed salary ranges. https://bloomberry.com/blog/i-analyzed-1000-forward-deployed-engineer-jobs-what-i-learned/

• Fortune coverage of MIT Project NANDA, "The GenAI Divide: State of AI in Business 2025" (August 18, 2025): 95 percent of enterprise generative AI pilots showed no measurable P&L impact; roughly 5 percent succeeded, typically with systems adapted to actual workflows. https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/

• S&P Global Market Intelligence, as reported by CIO Dive (March 14, 2025): share of companies abandoning most of their AI initiatives jumped from 17 percent to 42 percent; average organization scrapped 46 percent of AI proofs of concept before production; survey of more than 1,000 respondents in North America and Europe. https://www.ciodive.com/news/AI-project-fail-data-SPGlobal/742590/

• Gartner press release (June 25, 2025): more than 40 percent of agentic AI projects will be canceled by the end of 2027, due to escalating costs, unclear business value, or inadequate risk controls. https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027

• Palantir, "Dev versus Delta: Demystifying engineering roles at Palantir": Palantir's own account of Forward Deployed Software Engineers (Deltas) versus core product engineers; "one customer, many capabilities" versus "one capability, many customers." https://blog.palantir.com/dev-versus-delta-demystifying-engineering-roles-at-palantir-ad44c2a6e87

• Nabeel S. Qureshi, "Reflections on Palantir": the original FDE operating model, including onsite embedding three to four days per week and the field-to-product knowledge loop. https://nabeelqu.co/reflections-on-palantir

• U.S. Bureau of Labor Statistics, Occupational Outlook Handbook, Software Developers, Quality Assurance Analysts, and Testers: 2024 median pay $131,450; employment projected to grow 15 percent from 2024 to 2034. https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm

• RAND, "The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed": 65-practitioner interview study; organizational root causes including underinvestment in infrastructure to deploy completed work. https://www.rand.org/pubs/research_reports/RRA2680-1.html

• Archway product claims are first-party and match the published product facts at https://www.tryarchway.ai/ (llms.txt).