# Resource augmentation vs project delivery: which fits your team?

Resource augmentation fits when you already have a product owner, a backlog and a process, and what you lack is hands. Project delivery fits when you have a defined outcome and a date, and want someone else to own getting there. Between them sit two other models: forward deployed engineers, who embed inside your business to find and build what is worth building, and managed services, where the people who built a system also run it. Most organisations use more than one of these over the life of a relationship.

By Muhammad Ali Khoja, CSO. Published 2026-10-18.

## What are the four engagement models?

FetchSky works in four ways, and the difference is mostly about who owns the outcome and where the engineers sit.

Resource augmentation: experienced developers, QA engineers, DevOps engineers and designers join your team. They work in your tools and your process, report to your leads, and the headcount scales up or down as the roadmap changes.

Forward deployed engineers: engineers embedded inside your business, alongside the people doing the work. The brief is to find what is worth building, build it, and get it live. FetchSky uses this model especially for AI work, where the right opportunity is rarely obvious from the outside.

Project delivery: a defined scope and a date. FetchSky owns delivery, hands over at the end, and the builders stay reachable afterwards.

Managed services: FetchSky runs, monitors and improves what it built, with the engineers who wrote the code on call.

## How do the models compare?

|  | Resource augmentation | Forward deployed | Project delivery | Managed services |
| --- | --- | --- | --- | --- |
| Who owns the outcome | You | Shared | FetchSky | FetchSky |
| Where engineers sit | Your team, your tools | Inside your business units | FetchSky team | FetchSky team |
| Scope | Open, set by your backlog | Discovered on the ground | Fixed scope and date | Ongoing run and improve |
| Best when | You have a process and need capacity | You suspect value but cannot name the project | You can write the spec and need it delivered | You want the builders to keep it running |
| Commercial shape | Per person, flexible | Per engineer, time-boxed discovery then build | Fixed scope, agreed cost | Ongoing |
| Exit | Scale down | Hand to your team or move to a project | Handover, builders reachable | Hand back or continue |

## When does resource augmentation fit?

Resource augmentation fits a team that already ships. You have a product owner who can prioritise, a release cadence and a code review culture. What you lack is enough people, or a specific skill such as a Kotlin engineer for the next two quarters. Augmented engineers slot in and inherit your standards. If there is no process to join, they wait for direction and you pay for idle time.

## When does project delivery fit?

Project delivery fits when the outcome can be written down. A digital onboarding journey, a loyalty programme launch, a migration off an old core. You want a date, a cost agreed before work starts, and one party accountable. It suits regulated organisations where procurement needs a fixed proposal. Scope changes cost time and money, so it rewards clients who do the thinking up front.

## When should you choose forward deployed engineers or managed services?

Choose forward deployed engineers when you believe there is value, usually from AI, but you cannot yet name the project. The engineer sits with operations or finance, watches the work, and builds the thing that saves the most time. Choose managed services when a system is live and you would rather its builders carry the pager.

## Can you move between models?

Yes, and most long relationships do. A common path is a scoped project to build something, then managed services to run it, then augmentation when your own team wants to extend it. Another is forward deployed engineers to find an AI opportunity, a six-week pilot, then a project to roll it out. FetchSky has several client relationships over ten years old, and every one of them follows the same pattern: once a project is delivered, the client moves onto a retainer for support and improvements. The starting point is the same every time: a conversation, scoping, a proposal, then a start, usually within a few weeks. The full picture of what to expect from any of these is in [the engineering partner guide](/insights/working-with-an-engineering-partner).

If you are not sure which model fits, [how we work](/company/how-we-work) describes each one and how an engagement starts.

## Read next

- [Working with an engineering partner: a guide for technology leaders](https://fetchsky.com/insights/working-with-an-engineering-partner)
- [How we work](https://fetchsky.com/company/how-we-work)

Source: https://fetchsky.com/insights/resource-augmentation-vs-project-delivery