Forward-Deployed Engineer vs Solutions Architect: A Side-by-Side Comparison
Published · Updated
A Forward-Deployed Engineer (FDE) and a Solutions Architect (SA) both sit between a technology and the people who need it to work. The short answer to how they differ: an FDE is accountable for working software in the customer’s environment, and a solutions architect is accountable for the design decisions that software is built on. One spends most of the week in a codebase; the other spends most of it comparing options and defending a choice.
People often treat one as a junior or senior version of the other. They are better understood as different centres of gravity. This guide compares them side by side, walks one problem through both roles, and ends with a way to decide which direction fits you.
The comparison at a glance
| Dimension | Forward-Deployed Engineer | Solutions Architect |
|---|---|---|
| Accountable for | A working feature in production, in the customer’s environment | A system design that is safe, affordable and operable |
| Typical output | Merged code, integrations, fixes, a shipped increment | Architecture options, decision records, reviews, reference designs |
| How much code | Most of the week; commits to real repositories | Some; prototypes and proofs of concept, rarely production code on the customer’s systems |
| Time horizon | Days to weeks: ship, observe, iterate | Weeks to quarters: decisions that several teams live with |
| Relationship with the customer | Embedded; joins their standups and works in their tools | Advisory; runs discovery, reviews designs, unblocks decisions |
| Main risk they manage | The feature does not work on real data or real users | The design fails on cost, security, resilience or ownership |
| Strongest signal of skill | Shipping something useful into an unfamiliar codebase quickly | Explaining why one design beats the alternatives, and when it would not |
The rows describe emphasis, not hard walls. Good FDEs make design decisions every day, and good architects write code to test an idea. What differs is what each is ultimately held responsible for.
What a Forward-Deployed Engineer does
The role grew out of software companies that placed engineers directly with customers to build against their problems. Job descriptions for it, summarised in this explainer on forward-deployed engineers, keep returning to the same ideas: small teams, end-to-end ownership of high-stakes projects, and engineers who embed with a customer, learn their domain and build the solution alongside them.
In practice that means:
- Turning an ambiguous request into a scoped change. A customer rarely asks for a specific feature. They describe a problem, and the FDE finds the smallest version worth building first.
- Getting productive in someone else’s codebase. Reading unfamiliar code, finding where a change belongs, and making it without breaking what is already there.
- Integration work. Connecting the product to the customer’s data, identity system, and existing services is often most of the effort.
- Debugging in production. When it misbehaves on real data, the FDE is usually the person closest to the evidence.
- Feeding lessons back. The same explainer notes that FDEs “work with customers and also contribute to the product their company sells”. What breaks in the field becomes a product improvement.
In AI-enabled work, an FDE is also the person who makes a model useful on a specific customer’s data: retrieval over their documents, tool calls into their systems, and evaluation against their real questions rather than a demo set.
What a Solutions Architect does
A solutions architect is accountable for the shape of a system before and while it is built. The work starts with discovery: what the requirement really is, what constraints apply, and who will operate the result. It continues through comparing options and recording the decision.
Cloud providers formalise much of this thinking. AWS’s Well-Architected Framework organises design review around operational excellence, security, reliability, performance efficiency, cost optimisation and sustainability. Those are the trade-offs an architect is expected to reason about out loud.
Typical work includes:
- Discovery and requirements. Separating what the customer said from what they need, and finding the constraints nobody wrote down: data residency, existing contracts, team skills.
- Option analysis. Comparing two or three viable designs on cost, risk, latency and operational ownership, then recommending one.
- Decision records. Writing down why a choice was made, so the next team does not reverse it by accident.
- Design review and governance. Checking that what is being built still matches what was decided, especially around identity, data access and failure handling.
- Technical communication. Explaining the same design to engineers, security reviewers and budget holders in terms each can act on.
The same explainer draws the line between the two roles plainly: forward-deployed engineers are more hands-on and work with more ambiguity, while solutions architects are closer to an advisory role and rarely write code on the customer’s infrastructure. Read the day-to-day guide for Cloud/AI Solutions Architects for a longer look at the architect’s routine.
One problem, two roles
Suppose a logistics company wants an assistant that answers staff questions about shipments using its own policy documents and order system.
The solutions architect’s first questions are about shape and risk. Should answers come from retrieval over documents, from live calls to the order system, or both? Where may customer data be sent, and which model providers are acceptable under the company’s rules? What does it cost per thousand questions, and who gets paged when it is wrong? The output is a recommended design, the alternatives considered, and the guardrails: what the assistant may and may not do.
The FDE’s first questions are about getting something real in front of users. Which ten questions do staff actually ask most often? Can the order system’s API be called from where the assistant runs? What does the first version return for a real shipment ID? The output is a working slice in the customer’s environment, an evaluation set built from real questions, and a list of what broke.
Neither set of questions is optional. On a small team one person may ask both. On a larger engagement they are usually split, and the two roles depend on each other: the architect’s design is only as good as what survives contact with real data, and the FDE’s increment is only safe if it stays inside the agreed boundaries.
Where the paths overlap
Both paths now need a practical understanding of AI systems. That means model behaviour, context engineering, retrieval, tool use, evaluation, security and observability. Neither role is served by treating a model as a magic API that can be added after the architecture is finished.
Both also benefit from directing AI coding tools responsibly. The skill is not producing the largest possible diff. It is giving a tool enough context to make a bounded change, reviewing the result, and keeping a human accountable for the decision.
And both are customer-facing. Neither role suits someone who wants requirements handed to them fully formed.
Skills each role leans on
FDE leans on:
- Fluency in at least one production language and the ability to read others
- Debugging across boundaries: application, data, network and identity
- APIs, integration patterns and data plumbing
- Building and evaluating retrieval and tool-using AI features
- Writing short, clear updates for people who are not engineers
Solutions architect leans on:
- Cloud fundamentals in depth: networking, identity, storage, managed services and their limits
- Cost modelling and capacity reasoning
- Security and data-governance trade-offs
- Writing decision records and design documents that survive review
- Running discovery conversations and presenting options to decision-makers
The overlap is wide. The difference is which list you would rather be judged on.
Which direction fits you?
Lean towards Forward-Deployed Engineer if most of these are true:
- You get energy from opening an unfamiliar repository and finding your way around
- You would rather ship a rough working version on Tuesday than a perfect plan on Friday
- You like being close to the people who will use what you build
- You are comfortable being the person who debugs it when it fails
Lean towards Solutions Architect if most of these are true:
- You enjoy comparing alternatives and explaining why one is better
- You think about cost, failure and ownership before you think about features
- You like influencing several teams rather than owning one codebase
- You are comfortable defending a decision in front of people who disagree
If you tick roughly half of each list, start with the one closer to what you do today. A backend developer usually reaches the FDE direction faster; someone with infrastructure or platform experience often reaches the architect direction faster. Our backend developer to FDE timeline sets out what that first move looks like.
Can you switch later?
Yes, and many people do. A strong FDE learns architecture by watching which designs survive production, and a strong architect stays credible by understanding how systems behave in code. The common AI foundation keeps the two paths connected; what changes is the evidence you build. An FDE shows shipped features and what they learned from them. An architect shows decisions, the alternatives considered, and how those decisions held up.
Frequently asked questions
Is a forward-deployed engineer the same as a solutions engineer?
No. Solutions engineers and sales engineers usually support the sale: demos, technical questions and proofs of concept before a contract. An FDE typically works after the decision to build, writing production code with the customer and contributing back to the product. Titles vary by company, so read the responsibilities, not the label.
Do solutions architects write code?
Usually some: prototypes, infrastructure templates, proofs of concept and review comments. They are rarely the people writing production code on a customer’s systems week to week. That is the FDE’s territory.
Is FDE a sales role?
Not in the usual sense. FDEs are engineers who happen to work close to customers. They influence whether a customer stays and expands, but their output is working software, not a signed deal.
Which role is better for someone moving into AI work?
Neither is better in general. If you already write production code, the FDE direction lets you apply that experience to AI features quickly. If your strength is infrastructure, security or cloud design, the architect direction builds on it. Both require the same AI fundamentals first.
Do I need a computer science degree for either?
Neither role is defined by a degree. Both are judged on demonstrated work. See becoming a forward-deployed engineer without a CS degree for what to build instead.
Next step
The Forward-Deployed Engineer program follows the delivery-focused path: the AI foundation first, then shipping a grounded, tool-using feature inside an existing codebase. If design judgement and infrastructure are the stronger pull, the Cloud/AI Solutions Architect program takes the same foundation into architecture, governance and decision records.