What is a forward-deployed engineer, and why can’t your team hire one fast enough?
Written by
Yury Trushkov, Chief Technology and Delivery Officer
Last updated on:
October 23, 2026
Written by
Last updated on:
October 23, 2026
The forward-deployed engineer bridges powerful AI platforms and real-world outcomes by building software and redesigning workflows inside the customer’s business.
FULLSTACK FIELD NOTES · PART 2 OF 7
Getting value from an AI platform takes an understanding of the systems, decisions, and workflows of the business using it. Someone has to understand the customer’s problem, connect the technology to existing systems, and build a workflow people can use.
That’s where a forward-deployed engineer (FDE) comes in.
So how does an FDE differ from a solutions architect? Both roles call for technical depth, solution design, and close work with customers. The difference usually comes down to what each person is responsible for delivering.
A solutions architect focuses on how a platform should fit the customer’s requirements and enterprise architecture. An FDE works directly with the customer to build, test, and deploy the solution.
A forward-deployed engineer (FDE) is a software engineer embedded with customer teams to build, integrate, and deploy a working solution in the customer's environment. FDEs study the real workflow, prototype against real data, and write code that connects AI systems to existing systems, including the handoffs between AI agents and people.
The forward-deployed engineer role sits between a company's platform and the business problems it's meant to solve. Instead of handing off a design, the FDE stays with one customer, or a specific customer team, until the solution reaches production and delivers measurable outcomes.
Why forward-deployed engineering matters in the AI era
AI companies and tech companies can now ship platforms that do remarkable things in a demo. The gap appears when those platforms meet a real business: legacy systems, messy data pipelines, unwritten rules, and approval steps nobody has documented.
That's the whole idea behind the role. Large enterprises don't need another tool. They need someone who can connect the tool to the work and deliver real business outcomes. Forward-deployed engineers work directly with the people closest to the problem, so the solution fits how the business runs rather than how a slide deck says it runs.
The role also creates a feedback loop. Because FDEs see how many customers use a product in practice, they can bring what they learn back to the core product team and product managers, which helps shape product strategy for the next release.
FDE vs. solutions architect: What are the key differences?
Both roles call for technical depth, solution design, and close work with customers, and they often overlap. A solutions architect may write code, build a proof-of-concept, and guide complex deployments. An FDE also makes architecture decisions and helps stakeholders understand what’s technically possible.
The difference usually comes down to what each person is responsible for delivering. A solutions architect focuses on how a platform should fit the customer’s requirements and enterprise architecture. An FDE works directly with the customer to build, test, and deploy the solution.
Here’s how the work typically breaks down.
Forward-deployed engineer vs solutions architect responsibilities
Responsibility
Forward-deployed engineer
Solutions architect
Main focus
Building and deploying a working solution
Designing how the solution fits the customer's needs
Customer interaction
Working with users and business owners throughout delivery
Working with stakeholders to understand requirements and guide technical decisions
Hands-on work
Writing production code, building custom integrations, and testing workflows
Developing solution designs, reference architectures, and prototypes
Delivery ownership
Taking the build into production and planning the handoff
Guiding implementation, with delivery ownership varying by company
A solutions engineer or sales engineer often handles pre-sales calls, technical demos, and technical validation. They answer technical questions and help the customer evaluate whether the product meets their needs. An FDE may join those conversations, then stay involved after the deal closes to build custom integrations and handle post-sale delivery.
The same account may need all three roles at different points in the customer lifecycle. A sales engineer helps with the technical evaluation, a solutions architect works through the architecture, and an FDE builds and deploys the solution. On smaller teams, one person may cover several of these responsibilities.
Companies use these job titles differently, so hiring managers should be clear about who’ll write code, who’ll own deployment, and how internal teams will take over the work.
What does a forward-deployed engineer actually do?
An FDE’s work typically follows three stages.
First, they shadow the people doing the work
They sit with the adjuster, the underwriter, the support engineer, the procurement analyst. They watch where the days go. They notice the things the business owner stopped noticing years ago because the workflow’s been broken for so long.
Discovery calls provide useful context, but watching people work reveals details that a requirements document can miss.
They see where someone copies information between systems, where an approval stalls, and where a straightforward task depends on judgment that nobody’s documented.
Whether they’re at customer sites or working alongside users remotely, they need to understand how the work happens. As they gather requirements, they also identify where the workflow needs to change.
Second, they prototype against real data
They build something that calls real APIs, reads real documents, and produces a real output.
That might mean connecting data pipelines, building custom integrations, or writing glue code around legacy systems. The prototype needs to work in the customer’s environment, using the systems and data already in place.
It gives the business owner something concrete to evaluate. They can see how product capabilities apply to their workflow, while the FDE tests how data quality, permissions, and existing systems affect the result.
This is also where the FDE and the product team can learn from each other. A customer’s problem may reveal a missing feature, an integration that other paying customers could use, or a limitation that needs a different approach.
Once someone sees the new process running, the discussion can move from “Will this work?” to “How do my human employees and AI agents collaborate? Where are the seams?”
While a proof-of-concept helps answer those questions, it doesn’t finish the job. The team still needs to turn what it learns into a reliable production workflow.
Third, they ship the seam
The seam is the boundary between what the agent does and what the human does.
Which steps can the agent complete? Which decisions need human review? What happens when information’s missing, an integration fails, or an exception falls outside the expected workflow?
The FDE builds those boundaries into the production code, including the human handoffs, error handling, and escalation paths the system needs. Production-grade code also needs tests, monitoring, and a clear way to recover when something fails.
Before launch, they work with the implementation team to agree on code ownership, support responsibilities, and how changes will be tested. Internal teams need to know who’ll maintain the deployed system and what to do when something goes wrong. After launch, the FDE can work with customer success to track adoption metrics and see where users need support.
This takes both technical skill and business judgment. A workflow might be technically possible but still need human oversight because of compliance requirements, financial exposure, or the consequences of a wrong decision.
An FDE might say:
“Stage three should be agent-led, but stage four has to stay human because of the regulatory exposure. Stage seven needs a different handoff depending on the work type.”
A solutions architect might say:
“Here’s how our platform and integration patterns can support stages three through seven.”
Both are useful. The architect explains how the technology can support the process, while the FDE works through how each step will run and builds the software to support it.
Write production code and take a build through deployment.
Work with real data, APIs, and existing enterprise software.
Ask business owners useful questions and fill gaps in the requirements.
Turn workflow decisions into working software.
Explain technical trade-offs to customers and internal engineering teams.
A software engineer may have the technical skills but need support with stakeholder management. A solutions engineer may know how to work with customers but have less experience taking a system into production.
For FDE hiring, ask candidates to walk through a system they’ve shipped: what production code they wrote, how they handled the customer relationship, and what happened after launch. Ask how they worked with the product team when requirements changed or an integration failed.
Their answers should show how they handle messy environments, communicate decisions, and keep the work moving when the original plan needs to change.
When should your team hire a forward-deployed engineer?
You should consider hiring an FDE when your team can demonstrate what the platform does but struggles to turn that demonstration into a working business process.
Perhaps the proof-of-concept succeeds, but deployment stalls when it meets real data and legacy systems. The architecture may be clear, but nobody owns the custom integrations. Or the agent may work as designed while the team still needs to decide when a human should step in.
An FDE can work through these problems with the business owner and engineering team, from the prototype through deployment. For platform companies, a customer engineering team may already cover some of this work. Before adding the role, check where delivery is getting stuck and what responsibility the FDE will take on.
If your AI initiatives keep getting stuck here, consider funding this role.
Start with one. Pair them with one business owner who knows their process inside and out. Give them ninety days, a defined workflow, and clear responsibility for what gets shipped.
Then look at what they produce and ask whether it changes any of your assumptions about how the work could run.
A forward-deployed engineer (FDE) is a software engineer who works directly with customers to build and deploy software in their environment. For AI projects, that includes observing workflows, prototyping against real data, building integrations, and defining how AI agents and people work together in production.
What’s the difference between an FDE and a solutions architect?
A solutions architect typically focuses on how a platform should fit the customer’s requirements, systems, and constraints. An FDE focuses more on building and deploying the working solution. Since the roles overlap, ask who’ll own implementation and production delivery when defining either position.
Do forward-deployed engineers write production code?
Yes. FDEs build software that customers use in production, including application logic, data pipelines, and custom integrations. They also build in error handling and the steps that require human review.
How does an FDE differ from a solutions engineer?
A solutions engineer often supports the sales cycle through technical discovery, demos, and product evaluation, while an FDE focuses more on building and deploying the solution. Companies define these roles differently, so check the responsibilities rather than relying on the title.
When should a company hire its first forward-deployed engineer?
Consider hiring an FDE when promising AI prototypes repeatedly stall before production or don’t lead to workflows people can use. Start with one business process, one accountable business owner, and clear expectations for what needs to reach production.
How can you cut your AI coding costs without switching models?
This guide gives you the math, the meaningful benchmarks, and a six-step plan to cut spend without giving up capability.
Enjoyed the article? Get new content delivered to your inbox.
Subscribe below and stay updated with the latest developer guides and industry insights.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Iframe is blocked. Accept cookies to load it.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.