Consultant, Full Stack Engineer, or Forward Deployed Engineer?

Choose a consultant when the assignment needs a business decision or organisational change, a full stack engineer when it needs sustained application development, and a forward deployed engineer when it needs engineering close to a customer's changing operation. These are starting points for a brief. The person's demonstrated skills, agreed scope, and authority determine whether they can deliver it.

Understand what each role commits to

A consultant works under an advisory or delivery engagement. That can cover operating-model design, vendor selection, technical implementation, or a combination. Ask what the contract requires them to produce. An engineer employed by a consultancy can write and maintain production software; a management consultant's brief may end with a decision and an implementation plan.

A full stack engineer works across an application's user interface and server-side systems. Assess the relevant stack and deployment environment rather than assuming the title includes every infrastructure, security, or data skill. They may own an application from design through support, but the job title alone doesn't assign those responsibilities.

A forward deployed engineer, or FDE, works closely with customers to turn a product or technical capability into an operating deployment. The work commonly combines discovery, integration, implementation, and feedback to the team building the shared product. The employer's model determines how much custom software they write, what they support, and when they hand over.

Palantir's careers guidance places software engineers in Product Development and forward deployed software engineers in Business Development, with the latter responsible for technical and operational customer outcomes. That describes Palantir's organisation. It doesn't prescribe a reporting line for every company using the FDE title.

OpenAI's current London FDE description includes discovery, system design, full stack builds, production rollout, and field feedback to Product and Research. Its scope overlaps with both application engineering and technical consulting. Read the actual role description and delivery agreement before assuming that an FDE only configures a vendor's product.

A September 2026 Reddit discussion asks whether FDE is a new name for consultant. The thread identifies a question buyers and candidates have; its replies don't establish a standard definition. For a hiring decision, compare the work, commercial incentives, and support obligations behind the labels.

Test the skills that overlap

Discovery means learning how people complete the work, including the exceptions they handle outside the documented process. Each role can do it. Ask the candidate to trace a recent task from its initial request through the records, systems, and approvals it needed. Check whether they can distinguish a user's request from the problem the organisation needs to solve.

Product judgement means choosing what to build and what to leave out under real constraints. A consultant may establish the business priorities; a full stack engineer may refine them with users; an FDE may revise the deployment as field evidence arrives. Ask for a trade-off they made, the evidence behind it, and what they measured afterwards.

Coding competence needs its own evidence. Review a relevant implementation, including tests, access boundaries, error handling, and the deployment process. Let candidates explain their personal contribution and the help they received. A confident architecture discussion doesn't establish that they can repair the production system your team will operate.

Communication also has an engineering component. Someone needs to explain why missing records block a decision, translate a user's exception into a test, and tell sales when a promised date lacks evidence. Assess that work through a realistic scenario. Don't use conversational confidence as a substitute for technical competence.

Operational ownership covers what happens after launch. Request an example of an incident, a source-system change, or a handoff to another operator. Ask who monitored the service and who approved a rollback. A person can have strong implementation skills while needing a separate production owner for ongoing service.

Choose assessments that match the assignment. A small, paid exercise with synthetic records can reveal discovery and coding skills together. Agree its scope and time limit, and avoid requiring unpaid client work. Our FDE hiring guide covers a more detailed selection process.

Match the role to the assignment

Start by naming the uncertainty that prevents progress. You may lack agreement on which process to change, an application team to build an agreed workflow, or someone to resolve customer-specific constraints during deployment. These are different assignments even when each involves AI.

Use the table to start the conversation, then adjust for the person's evidence. A technically experienced consultant may handle the embedded deployment. A full stack engineer with customer discovery experience may perform the FDE assignment. Specify that work and allocate time for it instead of treating it as an extra duty.

Consider whose product the person represents. A vendor-employed FDE has an interest in successful use of that vendor's platform. If you need an independent comparison of products, give the evaluation to someone with an explicit independence requirement and disclose commercial relationships. A deployment role and a vendor-selection role can involve different incentives.

Pay attention to the duration of the need. A bounded discovery engagement can end with a decision and a receiving owner. A customer rollout may require an embedded engineer until agreed acceptance. An application with continuing releases needs continuity beyond a pilot. Match the contract and staffing arrangement to that ongoing work.

Don't assume any title guarantees speed or a lower price. Request the scope, dependencies, and staffing assumptions behind the estimate. Compare the cost of accepted work, including your staff's time and ongoing support. Day rates alone don't show the cost of achieving the operational result.

Give the project team clear decision rights

A compact delivery team can have a full stack engineer building the shared application, an FDE owning the customer deployment, and a sales lead managing the commercial relationship. That arrangement fits some projects. It still needs someone on the customer side who can decide how the process should work and accept the result.

The full stack engineer can own the application architecture, code review, and releases within agreed technical controls. The FDE can own the deployment backlog, local integration, and customer acceptance evidence. Give both a way to resolve changes that affect the shared product. Otherwise each customer can accumulate a separate version that nobody maintains consistently.

Sales owns what the company offers and negotiates, with technical review of feasibility before a commitment. A product manager owns shared priorities when several deployments compete for engineering time. An operating consultant may lead process design and change work. State when the same person holds more than one responsibility and how much capacity they have for each.

The customer's process owner decides business rules and the acceptance criteria. Their technology and security owners decide access and release permissions within company policy. The engineer can recommend a rule or design a control, but cannot grant themselves customer authority. Document who can approve a changed scope, data access, and production launch.

A deployment lead can coordinate a larger engagement. OpenAI's current deployment-lead description includes workflow mapping, success criteria, dependencies, and readiness and change management across delivery participants. It illustrates a separate coordination responsibility; it doesn't imply that every small implementation needs an additional full-time role.

Keep the decision process light enough to use. Record the named owner, the decision, and the escalation route in the project brief. Review unresolved dependencies during delivery. The AI deployment team guide explains how to scale the team around the work rather than filling a fixed set of titles.

Staff an AI order-intake project

Consider an illustrative distributor that receives orders by email and wants AI to prepare draft entries in its existing order system. This is a hypothetical staffing example, with no claimed client outcome. Staff still approve quantities, customer terms, and uncertain product matches before an order enters the fulfilment queue.

Begin with the current process. An operations consultant and the order-team leader can map the work and establish the baseline for staff time, errors, and rework. They identify which exceptions need a policy decision. The project should not encode a disputed pricing rule simply because an engineer found an example in an old email.

The full stack engineer builds the review application and the connection to the order system. Their scope includes authentication, draft storage, audit records, and tests for the supported cases. They work with the customer's technical owner on deployment permissions. The engineer needs a clear rule for which actions the application can take automatically.

The FDE works with the order team on representative records, product-code mappings, and the exceptions that appear during the limited rollout. They convert observations into acceptance tests and agree changes with the process owner. If the vendor's shared application needs a new capability, they take that requirement to the product owner rather than maintaining an undisclosed local fork.

The sales or account lead manages the contract and any scope change with input from delivery. A customer operations leader owns staff training and the approval process. A named production owner receives the runbook, alerts, and recovery procedure. These responsibilities continue even if the team combines several of the roles in two people.

A small distributor may use a consultant-engineer for discovery and deployment, with another engineer reviewing the build. A vendor serving many distributors may keep FDEs separate from the shared product team. The choice follows workload and continuity: count discovery, engineering, review, and support hours before assuming that one person can cover the whole engagement.

Define the handoff with observable evidence. The receiving operator can run the supported workflow, recognise an uncertain draft, and recover from a failed integration using the agreed procedure. The original engineer need not join every routine case. Set the support window and escalation route before calling the rollout complete.

Assess what AI coding tools change

AI coding tools can help people produce prototypes, explore unfamiliar code, and draft tests. That creates opportunities for consultants to implement more of their recommendations and for engineers to explore solutions with customers. Evaluate the actual workflow and output. Tool access doesn't establish competence in architecture, security, or production support.

Be careful with productivity headlines. In its February 2026 experiment update, METR said selection effects and time-measurement problems made its newer developer-productivity estimate unreliable. Researchers believed developers likely benefited more than in their early-2025 study, but described the evidence for the size of that increase as weak. Neither an older slowdown result nor a new headline gives you a staffing multiplier for your project.

Measure time to accepted work in your environment. Include discovery, implementation, review, and repairs after release. Compare tasks with similar complexity and quality requirements, and record who checked the result. More generated code can coexist with more review work; fewer typing hours don't automatically reduce total delivery effort.

Ask candidates to explain how they verify AI-assisted changes. They should identify which tests establish behaviour, how they check access boundaries, and how they handle uncertain dependencies. Let them use tools permitted in the actual job, while requiring them to explain the code and correct a failure. The assessment should reveal their judgement and ability to take over when the tool's answer is wrong.

Keep business approval with the authorised person. An AI tool can draft a mapping rule, but the process owner must approve the rule against the operation's requirements. An engineer must review and validate the implementation under the team's controls. Faster drafting doesn't settle a disagreement about customer terms or approve a production release.

Apply the comparison as an investor or operator

For a venture investor, examine the delivery work behind the startup's growth plan. Ask which customer problems the FDE handles, which improvements reach the shared product, and who supports mature accounts. An engineering-heavy deployment can support a strong business if the company prices and manages it. Inspect repeatability and ongoing labour rather than treating the title as evidence of product maturity.

Connect the team plan to the pipeline. If every customer requires discovery, custom integration, and months of support, the company needs capacity for those activities as well as product development. Verify whether founders still carry essential deployment duties outside the reported staffing plan. Our guide to FDE economics and product advantage covers that analysis.

For a PE operating team, decide which skills to share across portfolio companies and which responsibilities stay local. A central consultant can help compare workflows and frame the programme. Shared engineers can maintain connectors or an application. Each company still needs a process owner and someone to resolve local deployment constraints; an embedded assignment can supply the latter without moving business authority to the central team.

For an SME, identify the largest gap first. If the owner knows the process and needs an internal tool, a capable full stack engineer may be sufficient with clear review and support arrangements. If nobody agrees what the tool should do, fund discovery before the build. If a vendor's product repeatedly fails to fit local cases, request an engineer who can work through those cases with your staff.

For a large corporate, define the boundary between the deployment team and existing owners. Platform engineering, security, procurement, and operations may already hold relevant responsibilities. Give the FDE a route through those decisions and a realistic scope. Holding an embedded engineer responsible for delivery without access or approval support creates a bottleneck that a new title cannot resolve.

Write a brief that survives the job title

Write the assignment as a result someone can accept: for example, a supported draft-order workflow for agreed case types, with human approval before fulfilment. Name the source systems, expected users, and boundaries. State whether the engagement ends with a recommendation, production acceptance, or ongoing operation.

List the evidence you need before acceptance. That may include baseline and outcome measurements, tested integrations, access controls, and a receiving operator's demonstration. Specify who reviews each part. Agree how the team handles new requirements and who approves a change in cost or timing.

Record the skills and availability the assignment requires. Distinguish the ability to build from time available to build. Someone covering sales calls, discovery, support, and implementation needs a credible capacity plan. Identify the specialist work they will ask another person to perform and make that help part of the budget.

Agree code ownership, repository access, documentation, and support terms before delivery starts. Confirm the rights you need to maintain the result and the boundaries around customer data. Give the receiving team enough access and knowledge to continue operating when the engagement ends. Ask for appropriate professional review where contract terms need it.

Then choose the person or team whose evidence matches that brief. A consultant fits a decision or change assignment when their experience supports it; a full stack engineer fits sustained application work; an FDE fits customer-centred deployment with a path back to the product. Combining those skills can work, provided the scope, authority, and continuing responsibilities fit the people you actually have.