On this page
Key takeaways
- Staff augmentation sells seats; forward deployed engineering sells delivery; a consultancy project sells a scope.
- The client sets the roadmap under FDE and staff augmentation. Under a consultancy project the scope is fixed at signature.
- Risk of non-delivery sits with the client in staff augmentation, with the provider in a consultancy project, and is shared under FDE through baselines and quarterly resizing.
- Choose FDE for an approved roadmap with too few senior people; a fixed-scope project for one well-specified system; staff augmentation for a stable team with known gaps.
- Whatever the model, the code should belong to the client from the first commit.
Last updated: October 2026
Forward deployed engineering is a model where a provider's senior engineers work inside the client's team and systems and are accountable for shipping the client's roadmap. Staff augmentation is a model where a provider supplies engineers by the hour to fill seats on the client's team. A consultancy project is a model where a provider delivers a defined scope from its own environment and hands it over. All three add engineering capacity; they differ on who sets the roadmap, who owns the code, who carries the risk and how the engagement changes shape. Those differences decide which one fits, and the wrong choice is expensive: McKinsey's 2025 survey of 1,993 organisations found 88% using AI and 7% with it scaled across the enterprise, and the capacity model is part of why.
Who sets the roadmap?
Under staff augmentation and forward deployed engineering, the client sets the roadmap and changes it when the business changes. Under a consultancy project, the roadmap is frozen into a scope at signature, and a change means a change request, a renegotiation, or a quiet drift.
The practical difference between the first two is accountability for the roadmap being delivered. An augmented engineer is accountable for their own tickets. A forward deployed pod is accountable for the deliverables agreed with leadership, which is why it starts with a scoping period and a baseline.
Where does the work happen?
Forward deployed engineers and augmented staff work in the client's repositories, CI and tools. A consultancy project usually happens in the consultancy's environment, with a handover at the end. The handover is where context is lost: the decisions behind the code, the data quirks found along the way, the evaluation sets that were never written down.
Working inside the client's environment is slower in week one and faster by month three, because every decision is made where the data and the people are. Gartner predicts that organisations will abandon 60% of AI projects that lack AI-ready data through 2026; the data problems get found earlier when the engineers are sitting on the data.
Who owns the code?
The client should own the code, prompts, evaluations and data in every model, from the first commit. In practice staff augmentation and FDE deliver this by default, because the work lives in the client's repository. Consultancy projects deliver it at handover, and the contract decides whether the consultancy keeps any reusable components. A provider that will not put ownership in writing is selling a dependency.
How is success measured?
Staff augmentation is measured in hours billed and tickets closed. A consultancy project is measured by acceptance of the deliverables. Forward deployed engineering is measured against a baseline taken in the first weeks: lead time, throughput, defect escape, and the business number the roadmap is meant to move. The measurement decides the behaviour: hours reward presence, acceptance rewards the spec, baselines reward the outcome. The outcome is where the industry is weakest: ISG's 2025 survey of 400 senior AI decision makers found only 31% of enterprises with a top-three funded use case in full production, and a capacity model that measures hours has no view of that number at all.
How does the engagement resize?
Staff augmentation resizes by adding or removing people, usually with notice periods per person. A consultancy project resizes by change request. A forward deployed pod resizes each quarter: more engineers when the roadmap grows, fewer when the client's team has absorbed the work, with a handover plan built in from the start.
Cost structure: day rate, fixed price, hourly
Staff augmentation is billed hourly or monthly per person, with no delivery commitment. Consultancy projects are fixed price or time-and-materials against a scope, with margin for scope risk built into the price. Forward deployed pods are billed per engineer-day or per pod per month, with the size agreed each quarter, so the cost tracks the roadmap rather than the headcount. None of the three is cheaper in every case; the question is which cost the company can predict and which risk it can carry.
How the three models compare
| Forward deployed engineering | Staff augmentation | Consultancy project | |
|---|---|---|---|
| Who sets the roadmap | The client, resized quarterly | The client, ticket by ticket | Fixed at signature |
| Where the work happens | Client's repo, CI and tools | Client's repo, CI and tools | Provider's environment, handed over |
| Who owns the code | Client, from day one | Client, from day one | Client, at handover |
| Measured by | Baseline and roadmap outcome | Hours and tickets | Deliverables accepted |
| Risk sits with | Shared, through baselines and resizing | The client | The provider, priced into the margin |
| Who is accountable for shipping | The pod | The client's manager | The provider's project manager |
| Typical seniority | Senior only | Mixed | Mixed, senior at the top |
| Best for | Approved roadmap, missing senior people | Stable team with known gaps | One system, clearly specified |
Which model for which situation
- An approved AI roadmap, a small internal team, a deadline. Forward deployed engineering. The pod takes whole deliverables and installs its delivery system inside the team.
- One system with a clear spec, a budget and a launch date. A fixed-scope project. Acceptance tests agreed up front; code handed over in full.
- A stable, well-run team with two open seats. Staff augmentation. The process already works; the gap is people.
- A pilot that worked and will not reach daily use. Forward deployed engineering. The missing pieces are integration, evaluation and operating procedure, all inside the client.
- A platform already chosen, with the vendor's FDEs available. Use them, and keep an independent engineer close enough to judge what the platform cannot do.
- Nobody can say what the roadmap is. None of the three yet. An AI readiness assessment first.
Frequently asked questions
Can a forward deployed pod work alongside augmented staff?
Yes, and it often does. The pod brings the delivery system and the accountability for the roadmap; augmented engineers add capacity under the client's management. The two should share the same specs, review checks and dashboard so the quality bar is one bar.
Is forward deployed engineering more expensive than staff augmentation?
Per day, usually, because the engineers are senior and the pod carries accountability. Per outcome, often less, because the work ships and the client's team learns the system. The honest comparison is cost per roadmap item delivered and running, which staff augmentation rarely reports.
What happens to the code when the engagement ends?
Under all three models the client should keep everything. Under forward deployed engineering the delivery system stays too: specs, review checks, agents and dashboards, plus documentation and time spent pairing with the internal team before the pod resizes down.
