Forward Deployed Team, Staff Augmentation or a Fixed-Scope Project: Which One Fits

Three ways to get software built are often compared on price alone, and they are not the same product. A consulting project, staff augmentation and a forward deployed team differ in who carries the risk, how scope changes, and what you own at the end.

The fixed-scope consulting project

You agree a scope, a price and a date. The provider builds it and hands it over.

This works when you can describe the result accurately before anyone starts: a migration, an integration, a system with a known shape. The commercial model rewards both sides for keeping the scope still.

It goes wrong when the requirement moves. Every change becomes a variation, the variation becomes a negotiation, and the negotiation costs more time than the change. For AI work, where the requirement almost always moves after people see the first version, this is the main failure.

Staff augmentation

You hire people by the hour or the day. You manage them, set their work and carry the delivery risk.

It is flexible and it is fast to start. It suits a known gap in a team that already has a lead, a quality bar and a release process.

The weaknesses are familiar. You interview, onboard and quality check each person. When the contract ends, the knowledge leaves with them. And nobody except you is answerable for whether the whole thing works, because each person only owns their tickets.

A forward deployed team

You buy a small team: engineers, a lead and quality support, working inside your environment from your backlog, shipping every sprint.

The scope is not fixed, the team is. That is the trade. You can change what the team builds every two weeks without a variation, and in return you commit to the team rather than to a list of features.

It suits work where the requirements emerge from use, where the data cannot leave your tenant, and where you want the capability to stay with you afterwards. It is the wrong choice for a one-off piece of work with a hard edge, and it is poor value if your backlog is thin.

How to choose

• Can you write the acceptance criteria today, and will they still be right in three months? Buy a fixed-scope project.
• Do you have a strong lead and a quality process, and simply need more hands on defined tasks? Buy staff augmentation.
• Is the answer going to change as people use it, and do you need the work inside your own environment? Buy a forward deployed team.

A useful test: ask who is accountable when the thing is live and wrong. Under a fixed-scope project the answer is the contract. Under staff augmentation the answer is you. Under a forward deployed team the answer should be the team's lead, by name.

What it costs, and how to compare

An hourly rate tells you very little. Compare the three on total cost of getting a working result:

1. Time before the first useful thing is in production.
2. Management load on your own people, in hours per week.
3. Cost of change: what a new requirement costs in money and in delay.
4. What remains when the engagement ends: code, prompts, evaluation sets, documentation and trained staff.

Cheap hours with a heavy management load and nothing left over is the most expensive option on this list, and it is the one that looks best on a rate card.

Frequently asked questions

What is the difference between staff augmentation and a forward deployed team?

With staff augmentation you manage the people and carry the delivery risk. A forward deployed team brings its own lead, quality practice and method, works from your backlog, and is answerable for shipping each sprint.

Is a forward deployed team more expensive than contractors?

The hourly cost is usually higher and the total cost often is not, because the team manages itself, does its own quality assurance and leaves behind code, prompts and documentation your staff can maintain.

When is a fixed-scope project still the right choice?

When you can write the acceptance criteria now and they will still be correct at the end. Migrations, integrations and systems with a known shape fit the model well.

Can you start with one model and change later?

Yes, and many organisations do. A common pattern is a short fixed-fee assessment, then a forward deployed team for the build, then a smaller managed service once the work is stable.

Our Forward Deployed AI Engineering page describes the team, the sprint rhythm and what you get at the end of each one.