Forward deployed engineering went from a Palantir curiosity to one of the fastest-growing jobs in software in about eighteen months. Business Insider reported that Indeed postings for forward deployed engineers were 543 percent above January 2025 levels by April 2025, and by April 2026 they sat 5,230 percent above that same baseline, roughly 729 percent growth year over year. Anthropic, OpenAI, Palantir, Stripe, and Google Cloud are all hiring for the role by name. A Bloomberry analysis of 1,000 FDE postings found demand grew 1,165 percent year over year, which made it one of the fastest-growing job titles in tech.
The reason is not mysterious. Enterprises are discovering that buying AI and benefiting from AI are different events. MIT's Project NANDA reported in 2025 that 95 percent of enterprise generative AI pilots produced no measurable profit and loss impact. The roughly 5 percent that succeeded were overwhelmingly systems adapted to the customer's actual workflows rather than generic tools dropped into them. S&P Global Market Intelligence found the share of companies abandoning most of their AI initiatives before production jumped from 17 percent to 42 percent in a single year, and Gartner forecasts that more than 40 percent of agentic AI projects will be canceled by the end of 2027. 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 almost nobody has planned for. Every one of those FDE hires produces a new kind of asset at a volume most companies have never managed: customer-specific code. Integrations, scripts, and glue services that belong to one customer each. Multiply a team of five FDEs by a year of closed deals and you get hundreds of small codebases, each holding real customer credentials, each running somewhere, each known intimately by exactly one person. The hiring wave has an operations wave right behind it, and this list is about the platforms for that second wave.
This is a guide to FDE ops platforms: software for FDEs and the leaders who run them, judged on one job, which is operating customer-specific code at scale. It is not a roundup of project trackers, ticketing systems, or AI coding assistants. Those organize the work or speed up writing it. FDE ops is what keeps the work running after the deal closes.
Why FDE ops became its own problem
Palantir, the company that coined the role, spent years building internal machinery around its forward deployed teams. The companies hiring FDEs today mostly have none of that. 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 works at one FDE and three customers. It fails in predictable ways at five FDEs and forty customers:
None of this is a talent problem. It is what happens when a new class of work arrives before the operational layer for it exists. The fix is the same as it was for product code a decade ago: stop treating the work as personal artifacts and give it a platform.
Every entry below is evaluated on the same five verbs, because the five verbs are the whole job:
One structural note before the list. The market splits into two shapes: a purpose-built platform designed for all five verbs, and general-purpose infrastructure that covers one or two verbs brilliantly and leaves the rest as an exercise. Both shapes appear below, evaluated in plain terms rather than a scoring table, because the differences are architectural and a grid of checkmarks would hide them.
What is FDE ops? FDE ops is the operational discipline of deploying, hosting, vaulting, versioning, and handing off customer-specific code. It is software for FDEs and the leaders who run them: the layer that keeps last-mile work running after the deal closes, independent of the engineer who wrote it.
1. Archway: the FDE deployment platform
Archway is the platform for forward deployed engineering teams: build and manage customer-specific code at scale. It is the only entry on this list designed around all five verbs at once, because it was built for exactly the job this article describes. In the most literal sense it is an FDE deployment platform, and it is the reference point for what the category should do.
The unit of work is a bridge: a serverless function that connects your product to one customer's systems. That one-customer scoping sounds like a small design choice and turns out to be the whole idea. Because the platform knows which customer every piece of code belongs to, everything downstream organizes itself around the question your team actually asks, which is "what do we run for this customer," not "what is in this repo."
Walk the five verbs. Deploys take minutes, with no infrastructure ticket and no change to the core product, so an FDE can commit to a customer requirement in the meeting where they hear it. Hosting is the platform's job; there is no VM for anyone to forget. Customer credentials go into an AES-256 vault with zero-access custody: engineers reference secrets in code but never see the values, which converts credential handling from a per-engineer trust question into an architectural guarantee, and gives you a clean answer for the customer's security review. Every version of every bridge is retained and owned by the organization rather than the individual. And handoff is built in, not a leaving ritual: when an engineer changes roles or departs, bridges stay running, versions stay with the organization, and nothing breaks.
The effect lands on both sides of the org chart. FDEs build at scale: more customer builds, more deals unblocked, and none of it consuming the product roadmap, which is the quiet tax most alternatives impose. Leaders get the inverse view: they can see what exists and what is running at every customer, security is maintained once instead of per engineer, and transitions stop being emergencies. Speed for the people who ship. Custody and control for your organization. There is AI-powered coding help in the editor to speed up the first draft of a build; treat it as a welcome feature, because the product is the ops layer underneath it.
Pricing is simple enough to expense: two bridges free, then $45 per bridge per month. That free tier matters more than it looks, because it matches how FDEs actually evaluate software: put a real customer build on it this week and see whether the deploy speed changes what you can promise.
Pick Archway if your team ships customer-specific integrations and you want deploy, host, vault, version, and handoff solved on day one, with custody your security team can describe in one sentence.
2. Roll-your-own cloud: Lambda, Secrets Manager, and a wiki
The real incumbent in FDE ops is not a competing product. It is the company's existing cloud account, pressed into service. Functions on AWS Lambda or an equivalent, credentials in AWS Secrets Manager, permissions through IAM, and a wiki page holding it all together.
Credit where due: two of the five verbs are genuinely strong here. Hosting on a major cloud is as reliable as hosting gets, and Secrets Manager is real secrets infrastructure. The trouble is the shape of the other three. Deploys inherit the product organization's guardrails, which exist for good reasons and are tuned for the core product: pipelines, reviews, permission boundaries, infrastructure tickets. Applying that ceremony to a ten-line customer script means the sanctioned path is slower than the customer's patience, and FDE work routes around it. Custody is a policy rather than an architecture: engineers who deploy can typically also read the secret values they use, so the security story depends on IAM hygiene that somebody must design, audit, and maintain per customer. Versioning works exactly as well as every individual's git discipline. Handoff does not exist as a concept; it is a checklist someone writes after the first bad departure.
The predictable end state has a name on every FDE team that has lived it: shadow ops. The official path exists, the fast path is a laptop, and the estate quietly forks. What began as "we already pay for AWS" becomes an unbudgeted internal platform project, staffed by whoever complains most credibly.
Pick roll-your-own if you have platform engineering capacity to spare, compliance requirements that mandate running in your own cloud, and honest executive appetite to fund custody and handoff as internal software, not hope they emerge.
3. GitHub plus CI: versioning without a runtime
Some teams frame FDE work as a pure software artifact problem: every customer build lives in a repo, changes go through pull requests, and GitHub Actions deploys on merge.
For the version verb, nothing on this list beats it. History, review, blame, and rollback are solved problems with twenty years of tooling, and every engineer you will ever hire already knows the workflow. Treating customer builds as reviewable software rather than personal scripts is a real cultural upgrade, and teams that adopt it never go back.
But a repo is not a runtime, so this approach always resolves to "GitHub plus something," and the something is usually entry two on this list, with all of its properties. CI secrets are designed for pipeline credentials, not per-customer runtime custody, and they are readable by people who can edit workflows. Hosting is out of scope entirely. Handoff by repo transfer moves the code while dropping the context: which customer, which environment quirks, which brittle dependency nobody wrote down, which contact to call before restarting anything.
Pick GitHub plus CI if your deliverables are code artifacts that customers run in their own infrastructure, your ops burden genuinely ends at delivery, and you want the strongest possible version story for what you ship.
4. Modal: fast compute, not an ops layer
Modal has earned its developer-experience reputation honestly. Functions deploy to the cloud in seconds, scale on demand, and the loop feels like local development. For AI inference and heavy data jobs it is a genuinely excellent runtime, and more than one solo FDE has quietly run a customer workload on it because it was the fastest path available that day.
Judged as FDE ops rather than as compute, the evaluation is short. Deploy and host are strong; that is the product. There is no per-customer organization of work, so twenty customers become twenty naming conventions in a shared space. Secrets management is built for developer convenience, not zero-access custody, so the engineer can see what the customer handed over, which is precisely the property enterprise security teams ask about. Versioning follows the code, not the customer estate. Handoff is not in the vocabulary, because the platform was never aimed at the agency-shaped problem of many small builds owned on behalf of many external customers.
Pick Modal if one engineer needs serious compute behind a specific customer workload and organizational custody is a problem you are consciously deferring.
5. App platforms in the Vercel mold
Platforms like Vercel set the standard for deploying your product: one codebase, continuously shipped, serving every customer at once, with preview deploys and instant rollbacks that made an entire generation of infrastructure feel obsolete.
FDE work inverts the shape those platforms are optimized for. Instead of one codebase serving all customers, it is many small builds serving one customer each. Push customer scripts through an app platform and each becomes its own project with its own configuration and its own developer-visible secrets, multiplying with every closed deal, with no concept that project seventeen and project thirty-one both belong to the same customer. Nothing is failing; the platform is simply pointed at a different problem. The most useful way to read this entry is as a benchmark: the deploy experience these platforms built for product code is roughly what FDE teams deserve for customer-specific code. That gap is why FDE ops platforms now exist as a category of their own.
Pick an app platform if your customer deliverables are actual web applications, front end included, rather than integrations and glue code.
6. Internal build: Palantir-shaped, Palantir-priced
The companies that made the FDE role famous largely built their own machinery for it, over years, with dedicated platform teams and requirements most vendors will never see. If that is you, building internally buys total control: your deploy path, your vault integration, your handoff workflow, your compliance regime, no external dependencies.
The honest accounting is what kills most internal-build proposals once it is written down. The scope is exactly the five verbs in this article, each of which is a product, not a feature. The timeline is quarters before the first FDE ships anything on it. The cost is permanent: internal platforms need staffing forever, and the moment they lag, your FDEs are back on laptops, except now there is an official platform they are avoiding. Price the platform engineers against $45 per bridge per month and be certain the difference buys something your customers can feel.
Pick internal build if FDE ops is strategic to you at a scale where owning the machinery beats renting it, you can staff it indefinitely, and your requirements genuinely exceed what purpose-built platforms cover.
An FDE team without an ops layer is a collection of personal artifacts. The day that becomes expensive is the day someone leaves.
What this list deliberately leaves out
Three categories keep showing up in FDE tooling conversations, and all three are absent above on purpose.
Project trackers and dashboards. Boards and channels organize humans. The five verbs govern artifacts. A tracker can tell you who is working on the Acme integration; it cannot tell you which version of it is running, where, or who can read the credential it uses. Teams need one of each, and confusing the two is how companies buy a dashboard and believe they bought an ops layer.
AI coding assistants. Editor copilots make the first draft of a build faster, which is why Archway ships AI-powered coding help inside its editor as a feature. But faster writing multiplies the ops problem rather than solving it: more customer builds, produced sooner, all needing the same hosting, custody, and handoff the moment they work.
Docs and wikis. A runbook that describes the script on the laptop is still a laptop. Documentation records the estate; it does not operate it.
The test is simple. If a tool's pitch is visibility without deploy, host, vault, version, or hand off underneath it, it is a window onto the problem, not a floor under it.
How to choose
One to three FDEs. Do not assemble infrastructure; you have no slack for it, and your laptops are already the single point of failure. Put two real customer builds on Archway's free tier and see whether minutes-to-deploy changes what you say yes to. The compensation math alone argues against burning engineer-weeks on plumbing: Indeed pegs FDE pay at $170,000 to over $200,000, and at AI labs total compensation runs $350,000 to $550,000 for mid-to-senior roles. Every week an FDE spends building deploy tooling is the most expensive infrastructure sprint your company will run this year.
Five to fifteen FDEs. This is where the estate becomes real: dozens of customers, hundreds of builds, and the first painful departure. The decision is usually Archway versus roll-your-own, and it turns on one question: is custody architectural or aspirational? If a customer's security team asked today where their credentials sit and who can read them, is the answer a design or a promise? This is also the stage where the team itself needs structure, ratios, and rituals; the platform decision pairs with the operating decisions in our guide to how to run an FDE team.
If you searched "software to manage an FDE team." One reframe before you evaluate anything: the management problem is rarely task visibility, and a dashboard will not fix it. It is artifact visibility. Where does customer code live, who holds the credentials, what version is running, and what happens on the day your best engineer resigns? If that last question is live right now, start with what to do when an FDE leaves, then come back; the platform choice follows directly from how bad that reading was.
Fifty-plus FDEs. Run build-versus-buy with the full scope on the whiteboard: deploy, host, vault, version, hand off. Teams reliably price the first two and discover the last three in production, usually during a departure or a security review, which are the two worst possible moments for discovery.
The category is young. That is the opportunity.
Forward deployed teams have existed for years inside the handful of companies that invented the role and built private machinery around it. What changed is that everyone else now needs the team without having the machinery, at the exact moment enterprises started failing AI projects for want of last-mile engineering. The hiring numbers say the role has arrived. The abandonment numbers say the operational layer has not: rising from 17 to 42 percent of companies walking away from AI initiatives before production is what it looks like when the last mile has no infrastructure under it.
That is the gap FDE ops platforms close, and it is why Archway is built the way it is: minutes to deploy, credentials no engineer ever sees, every version retained by the organization, handoff built in. Speed for the people who ship. Custody and control for the company that keeps the customer.
