AI models are advancing fast, but getting them to work inside real business environments is still the hard part. That's where forward deployed engineers come in, and it's why we're introducing FDE as part of our own practice at AltexSoft.
By combining engineering expertise with deep domain knowledge, FDEs help companies move from a business challenge to a working solution.
In this post, we uncover what a forward deployed engineer actually does, how to tell if your company needs one, and how to make the most of such an engagement.
What is a forward deployed engineer?
A forward deployed engineer (FDE) is a senior, customer-facing tech specialist who builds, adapts, and operates a software product (or the engineering process behind it) within that customer's real environment.
The FDE boom
TL;DR: The FDE role is rapidly gaining popularity; many major software/AI vendors are now building FDE teams.
Pioneered and popularized by Palantir, this role has become tech’s most sought-after position in the era of AI and complex data systems.
FDE job postings on Indeed grew from 643 in April 2025 to 5,330 in April 2026, a 729 percent year-over-year jump. Andreessen Horowitz has called it the hottest job in startups. Forward deployed PMs are becoming more common, too.
Major technology companies are investing heavily. In May 2026, OpenAI launched the OpenAI Deployment Company with $4 billion in initial backing and acquired the Edinburgh-based consultancy Tomoro, bringing roughly 150 forward deployed engineers on day one.
Anthropic followed closely with Ode. Google is recruiting hundreds of engineers for a similar embedded-deployment function. ServiceNow and Accenture launched a joint FDE program. Infosys, Salesforce, and many others are scaling their FDE teams to embed engineers inside customer environments and build agentic workflows.
The era of the pilot is over. The era of the agent is here.
Why forward deployed engineering is gaining attention now
TL;DR: AI implementation is the hardest part, especially in legacy infrastructure; AI products must be tailored to each business environment to deliver value.
A widely cited MIT study found that about 95 percent of enterprise genAI pilots showed no measurable P&L impact.
AI models keep getting better, and demos keep showing what’s possible. Businesses want those benefits, but implementing AI in the real world, with their own data, workflows, and legacy systems, is much harder. There's no universal playbook: every deployment comes with its own constraints.
Enterprises buying AI are like your grandma getting an iPhone: they want to use it, but they need you to set it up.
For some clients, the problem isn't the product itself; it's that their engineering team lacks an effective process for integrating AI into their development workflow.
Those gaps are where forward deployed engineers come in. They take a company’s specific, often messy problem, determine the best way to solve it, and adapt technology and processes to fit the business environment.
AI is driving much of the current demand, but FDE isn’t exclusively an AI role. The same model applies to complex software, data platforms, integrations, modernization projects, and other situations where off-the-shelf technology must be adapted to the realities of a specific business.
What does an FDE actually do?
TL;DR: An FDE works closely with the client's business and technical teams and owns a problem from discovery through working production software.
What to expect from an FDE engagement
An FDE can work as a single specialist or, if the problem is larger than one person can handle, bring in the team.
Understand the actual business problem. Talk to stakeholders, inspect existing systems and workflows, identify constraints, and separate symptoms from the underlying problem.
Narrow the problem to a valuable first outcome. Determine what should actually be built first to prevent a lengthy engagement when a smaller intervention can prove or disprove value.
Design and prototype the solution. Define architecture, technology choices, data requirements, integrations, UX/workflow, etc.
Build inside the customer's actual environment. Integrate with APIs, legacy applications, identity, data infrastructure, cloud systems, or third-party products.
Establish the processes and practices around the solution. Set up development workflows, operational practices, AI adoption processes, governance, and team structures required to successfully build, run, and scale the solution.
Productionize and deploy. Test performance, reliability, security, and operational readiness.
Drive adoption and iterate. Watch how real users interact with the system and adjust the solution.
Transfer knowledge and/or identify reusable patterns. A mature FDE engagement should leave behind code, documentation, operational knowledge, and an internal team capable of continuing the work.
We put one senior engineer inside your operation. Within weeks, you have one real AI improvement running in your own production systems, with the tests and monitoring to keep it working — and your team owns all of it.
FDE vs IT consultant vs solution architect vs software engineer vs staff augmentation
Forward deployed engineers overlap with several familiar technology roles, but differ mainly in the level of ownership.
FDE compared to other roles
FDE vs IT consultant. Consultants typically analyze a problem and recommend a solution. FDEs go further: They help define the solution and then build and deploy it themselves.
While advisory engagements often end with recommendations and architecture, FDE engagements are expected to deliver working software.
FDE vs solution architect. Solution architects typically focus on matching an existing product to customer needs, often around presales, solution design, demos, and adoption. FDEs take deeper ownership of production delivery, writing custom code and integrations when the product alone isn't enough.
FDE vs software engineer. Software engineers primarily build against defined product requirements or a backlog. FDEs operate closer to the business problem, helping shape requirements as they build.
Metaphorically speaking, the core engineer builds the engine; the FDE installs that engine into a specific, running vehicle.
FDE vs staff augmentation. Staff augmentation adds engineering capacity to an existing team and delivery process. An FDE adds ownership: They can take an ambiguous business problem and drive it from discovery to a working solution.
When do you need a forward deployed engineer – and when you don’t?
TL;DR: If you know something is broken or stuck but can't specify the fix, you need an FDE. Or, if your digital transformation project is trapped between a vendor who doesn't understand your business and an internal IT team that doesn't understand the vendor's tech.
Our FDE turns a stuck AI ambition into a working system running in the client's own production, within weeks, that the client's team can keep running after we leave.
Consider an FDE in these cases.
You have a high-value business problem but no clean technical specification. For example, “we need to reduce manual reconciliation by 50 percent” rather than “build these seven endpoints.”
A promising prototype isn't reaching production. That’s especially relevant for AI products that need to be securely wired into your proprietary data and workflows.
Your engineers lack specific domain or technology expertise. The FDE can both solve the problem and transfer knowledge.
Time-to-value matters more than perfect upfront planning. FDEs bypass the standard "telephone game" of requirements gathering because the person gathering the requirements is also writing the code.
Requirements are likely to change after users see the solution. You need rapid discovery/build feedback rather than requirement-document handoffs.
The project spans many systems or departments. The major challenge is orchestration rather than pure coding.
The initiative requires close collaboration between business and engineering.
An FDE works well when companies know what they want to achieve, but not exactly how to build it. But it's not a fix for a weak product-market fit or an unclear strategy. An FDE can execute against ambiguity, but they can't manufacture a business case that isn't there yet.
In the more straightforward cases, a different specialist usually fits better. For example, if the requirements are clear but the technical design isn't, a software architect may be enough. If both the solution and requirements are clear and you mainly need more engineering capacity, staff augmentation or a conventional development team may be a better fit.
FDE risks and how to manage them
If you consider bringing in an FDE, you must account for potential complexities.
Key-person dependency. An embedded engineer accumulates enormous context.
Mitigation: pairing with internal specialists, documentation, internal ownership, and structured handoff.
Too much customer-specific code. FDE speed can create one-off solutions that become difficult to maintain.
Mitigation: architecture oversight and deciding deliberately what should be reusable versus bespoke.
Security and access. An embedded engineer may need unusually deep access to repos, systems, data, and business processes.
Mitigation: least-privilege access, security reviews, client environments, and auditability.
Scope creep. Close access to business users generates an endless stream of requests.
Mitigation: agree on the target outcome and move new opportunities into a separate backlog rather than continuously expanding the engagement.
FDE becoming an expensive generalist. If every ordinary engineering task reaches the FDE, the model loses its economic value.
Mitigation: use them for uncertainty, cross-functional complexity, and high-impact decisions; transition repeatable work to the broader engineering team.
Speed creating technical debt. The FDE model rewards rapid iteration, which can tempt teams to optimize for the immediate deployment at the expense of architecture and maintainability.
Mitigation: define production standards upfront and subject FDE-built software to the same architecture, security, testing, and code-review requirements as other production systems.
None of these are reasons to skip the model; they're reasons to pay close attention to how you structure the engagement.
How to make the most of an FDE engagement
Whether the engineers are internal or brought in, successful engagements tend to share a few common traits.
Define success before the engagement starts. Decide on specific KPIs up front. These can be delivery metrics (time to first working prototype, time to production, lead time for changes, or integration milestones); product/adoption metrics (active users, workflow adoption, task completion, reliability/quality); or business metrics (revenue generated, cost reduced, hours saved, conversion improvement).
Start with one high-value problem, not a company-wide transformation. Choose something narrow enough to ship and measure, but important enough that solving it creates meaningful business value.
Give the FDE access to the people who actually do the work. Requirements filtered through several management layers defeat much of the FDE model. Direct access to domain experts and end users helps the engineer understand how the process really works.
Prepare the system and data access early. Security reviews, credentials, test environments, data permissions, and vendor approvals can take longer than development itself. Start them before the engineer needs them.
Give the FDE real authority to ship code (with guardrails). If they have to file a request and wait for someone else's sprint to pick it up, you’ve missed the point.
Pair the FDE with an internal owner. An internal engineer or technical lead should work alongside the FDE so that context, architectural decisions, and operational knowledge remain in the organization.
Establish rapid, C-level feedback loops: FDEs thrive on momentum, so don't wait for quarterly reviews. Establish frequent check-ins between the FDE, the business stakeholder, and engineering leadership to unblock compliance or access issues immediately.
Agree on the exit condition. An FDE shouldn't become a permanent dependency by default. Define what must be running, documented, monitored, and transferred before the engagement is considered complete.
Forward deployed engineering at AltexSoft
AltexSoft's FDE model places an experienced engineer close to the client's business and engineering teams, while allowing that engineer to rely on AltexSoft's broader capabilities in architecture, software engineering, AI/data, cloud, UX, etc.
One of the key cases for an FDE engagement involves setting up Interlace, AltexSoft's proprietary knowledge graph platform built to make sense of complex, legacy, poorly documented systems. It connects code, documentation, architecture, and business logic in real time, giving teams and AI agents the context they need to work effectively.
A typical engagement starts with one narrow, high-value problem. Before development begins, we agree on what success looks like, the engagement time box and cost, and what the client will own at the end, from code and agents to documentation and operational knowledge.
If our FDE discovers that a problem is fundamentally larger than one person can handle, we inform you immediately, before you get into the wrong shape of engagement.
Access and security are planned from the start, since enterprise approvals can take weeks. Once embedded, the FDE works directly with the client's domain experts and technical teams to understand the problem, build the solution in the real environment, test it, and get it into production.
The engagement ends with either a working result the client owns and can continue operating, or a clear account of what prevented the target from being reached. Depending on the problem, what gets left behind can also include a working AI SDLC, meaning coding agents, review, and testing wired into the client's pipeline to support AI-assisted development.
AltexSoft brings a proven delivery record inside live travel operations. Because our engineers already understand PSS and GDS integrations, disruption management, and OTA/TMC workflows, we bypass the standard learning curve. We get to the root of your business problem on day one.
Photo by Saint Rambo on Unsplash
Maria is a curious researcher, passionate about discovering how technologies change the world. She started her career in logistics but has dedicated the last five years to exploring travel tech, large travel businesses, and product management best practices.
Want to write an article for our blog? Read our requirements and guidelines to become a contributor.