When the roadmap needs more engineering than your team can deliver, there are three common ways to get it from outside: add people to your team, hand a running service to a provider, or contract a project with an agreed scope. The day rates differ less than the contracts do. Each model settles who directs the work and who pays when it runs late.
What is staff augmentation? The meaning, and the two models it is compared with
Staff augmentation means adding outside engineers to your own team for a period of time. They work in your repositories, join your stand-ups and take tasks from your backlog, and your team lead directs them the way they direct employees. The vendor supplies people with the agreed skills and invoices for their time, by the hour, the day or the month.
The vendor's promise ends there. It commits to people and hours; whether the feature ships on time stays with you.
Team extension: staff augmentation with one employer behind the team
Team extension is a variant you will meet in proposals, ours included. The engineers are employees of one company rather than individual contractors, they usually stay for years rather than months, and the vendor handles hiring, leave cover and replacements. You still direct the work and own the result.
Managed services
In a managed service, a provider takes over a defined function and runs it: application support, infrastructure, monitoring, security operations. You pay a recurring fee and hold the provider to a service level agreement, a contract that, in the definition NIST's glossary takes from CNSSI 4009, defines the specific responsibilities of the service provider and sets the customer expectations
(NIST). Who does the work, and how, is the provider's business. You see the results in response times, availability and monthly reports.
Project outsourcing
With project outsourcing, you pay for a result with clear edges: a customer portal, an integration, a migration. The provider staffs and manages its own team, agrees the scope with you and delivers it, for a fixed price or on time and materials against an estimate. Once you accept the work, the system comes back to your team or moves to a support contract.
Side by side, the three models look like this:
| Staff augmentation | Managed services | Project outsourcing | |
|---|---|---|---|
| What you pay for | Engineers' time | A running service at an agreed level | A defined scope, delivered |
| Who directs the daily work | Your team lead | The provider | The provider's project manager, against the agreed scope |
| How you pay | Hourly, daily or monthly rate per person | Monthly fee, sometimes with service credits | Fixed price, or time and materials against an estimate |
| Typical length | Months to years | A minimum term, then rolling | Weeks to months, until acceptance |
| Fits best when | You have technical leadership and more backlog than people | A stable system has to keep running | The goal can be written down before work starts |
The table shows what each contract says. The more useful comparison is what happens when something goes wrong.
Who owns delivery and risk in each model
Each contract moves a different set of risks to the provider. A simple test is to ask, for each risk, who loses money if it happens.
| Risk | Staff augmentation | Managed services | Project outsourcing |
|---|---|---|---|
| The work is late or over budget | You: you pay for the extra hours | The provider, within the agreed fee and scope | The provider on a fixed price; you on time and materials |
| The result is poor | You, through your own reviews | The provider, measured against the SLA | The provider, until you accept the work |
| Someone leaves | The vendor sends a replacement; the knowledge leaves with the person | The provider | The provider |
| Knowledge of the system | Builds up in your team, if you write it down | Builds up at the provider | Stays at the provider until handover |
| Employment law | Highest exposure: the people work under your direction | Low | Low |
| Your management time | High | Low once the service runs | Medium: scope, reviews and acceptance |
US federal procurement rules state the trade-off plainly. A firm-fixed-price contract places upon the contractor maximum risk and full responsibility for all costs and resulting profit or loss
(FAR 16.202-1), while a time-and-materials contract provides no positive profit incentive to the contractor for cost control or labor efficiency
(FAR 16.601). Private contracts follow the same logic, and the price reflects it: a vendor that carries the overrun risk builds a margin for it into the quote.
Is a fixed price then the safe choice? Only when the scope is stable. Every change after signing becomes a change request, priced by the party that now holds the risk.
The legal side of putting outside people under your direction
Staff augmentation carries one risk the other two models mostly avoid. The engineers work inside your organization and take instructions from your managers, and labor law in several countries looks at exactly that.
In Germany, the Arbeitnehmerüberlassungsgesetz treats workers as lent when they are integrated into the work organization of the hirer and subject to its instructions
(§ 1(1), our translation). Lending workers needs a license, the same person may as a rule be lent to the same client for at most 18 consecutive months, and if the provider has no license, the law deems an employment relationship between the worker and the client (§ 10). The test looks at how the work is organized, so the title of the contract does not settle the question.
In the UK, the off-payroll working rules (IR35) have since 6 April 2021 made medium and large private-sector clients decide whether a contractor working through their own company would be an employee if engaged directly. The client issues a Status Determination Statement with its reasons and must answer a disagreement within 45 days (HMRC guidance).
Does that make staff augmentation a legal risk to avoid? No. Both countries allow it, but in both the client has duties of its own, so ask a provider how its contracts handle this in the country where your managers direct the work, before the first engineer starts.
Staff augmentation vs managed services: cost and control
On the invoice, staff augmentation usually looks cheapest: a rate for each person and nothing else. The costs that are not on the invoice stay with your team. Onboarding, code reviews, daily direction and the weeks a replacement needs to learn the system are all paid for in your own people's time.
A managed service turns most of that into one monthly fee. You give up control over how the work is done, and in return you stop managing it.
| Staff augmentation | Managed services | Project outsourcing | |
|---|---|---|---|
| What the invoice covers | Hours of named people | The service at the agreed level | The agreed scope |
| Costs that stay with you | Management, onboarding, reviews, ramp-up of replacements | Defining the service, reading the reports | Writing the scope, reviews, acceptance testing, change requests |
| Price predictability | Monthly cost known; the total depends on how long the work takes | Fixed monthly fee within the agreed coverage | Price known up front; changes cost extra |
| Control over how the work is done | Full | Low: you set the what, the provider the how | Low during delivery, high at acceptance |
| Time to start | Weeks | Longer: an onboarding phase comes first | Longer: scope and contract come first |
| Ending it | Notice period per person | Minimum term, notice and a transition plan | At acceptance, or termination on agreed terms |
So which one is cheaper? Per hour, staff augmentation. Per working feature, it depends on whether your team has the time to lead the extra people. A tech lead who spends half the week directing contractors is a cost too, even if it never appears on a vendor's invoice.
Companies keep moving work between these models as their needs change. In Deloitte's 2024 Global Outsourcing Survey of more than 500 executives, 80% planned to maintain or increase their investment in third-party outsourcing, and 70% had selectively brought scope back in-house from a third party over the previous five years. Deloitte also lists skilled talent and agility next to cost reduction as the main reasons to outsource (Deloitte; Deloitte sells sourcing advice).
When team extension fits, and when another model is the better choice
The right model follows from your situation more than from the price list:
| Your situation | Model that fits | Why |
|---|---|---|
| You have a tech lead with time to direct more people, and the backlog keeps growing | Staff augmentation or team extension | You keep the decisions; the bottleneck is people |
| You will need the extra engineers for a year or longer | Team extension | Replacements and leave cover are the vendor's job, and knowledge stays in a stable group |
| A stable system has to keep running, and nobody on your team wants the pager | Managed services | You pay for an outcome you can check every month |
| You need a defined product and have no engineering team | Project outsourcing | Someone has to lead the work; with augmentation, that would be you |
| A specialist job: a performance problem, an audit, a migration | A scoped project | Specialists deliver a result faster than they can join your routines |
| A project is late and the date cannot move | Usually none of them: cut scope first | New people slow a late project down before they speed it up |
The last row has a name: Brooks's law. Fred Brooks put it in The Mythical Man-Month in 1975: Adding manpower to a late software project makes it later
(quoted by Martin Fowler). New engineers need time from the people who know the system, at the moment those people have none to spare.
Team extension fits best in the first two rows. It works when you can name who on your side sets priorities, reviews code and decides architecture. If nobody can, the extra engineers wait for direction, and you pay for the waiting. In that case a provider that runs the work as a project is the better choice, even at a higher rate.
Staff augmentation best practices: onboarding the people you bring in
Contractors are new hires in every sense that matters for onboarding. They need access, context and people to ask, and the client is the only one who can give them those.
Microsoft surveyed 267 new hires who joined software teams remotely during the pandemic. Most never met their teammates in person, and the authors found one of the biggest challenges faced by these new hires, building a strong social connection with their team
(Rodeghero et al., ICSE 2021). Their recommendations read like a checklist for an augmented team: an onboarding buddy, a technical mentor, one-to-one meetings, a simple first task and up-to-date documentation.
GitLab, which runs its engineering remotely, starts onboarding as soon as the candidate has officially accepted the offer
. An onboarding issue lists tasks for the hiring manager, the buddy and HR, and new engineers pair with their buddy on their first few merge requests (GitLab).
Written knowledge matters more than usual, because outside engineers lack the corridor history your employees carry. In Stack Overflow's 2024 survey, 61% of developers spent more than 30 minutes a day searching for answers or solutions (Stack Overflow). A newcomer with no one to ask is likely to spend longer.
The checklist below puts these practices in order:
| When | What to have ready | Who owns it |
|---|---|---|
| Before day one | Accounts, VPN, repository and environment access working; hardware or a virtual desktop approved | Your IT and the team lead |
| Before day one | A named buddy from your team, and one onboarding issue with tasks for the newcomer, the buddy and the lead | Team lead |
| Day one | An architecture walkthrough, the path from ticket to production, and who decides what | Team lead or architect |
| First week | A small, real task that goes through the full review and release process, paired with the buddy | Buddy |
| Weeks two to four | All team routines, the same as employees; regular one-to-ones with the lead | Team lead |
| End of month one | A review of pace, quality and communication, and a fix for whatever is blocking | Team lead and the vendor's lead |
| Always | Decisions and system knowledge written down, so they stay when people leave | Everyone |
The people side matters as much as the access list. When Google studied what made its teams effective, psychological safety came first in order of importance: whether people feel safe to ask a question or admit a mistake without being seen as incompetent (Google re:Work). An external engineer who is unsure of their standing asks fewer questions. Treat them as members of the team from the first day, in meetings, in reviews and in credit for the work.
How we work in each model
We offer all three, and the first call is where we say which one fits.
Java team extension is our version of staff augmentation. Our engineers are direct employees in Poland, inside the EU, with no subcontracting. You review profiles and interview candidates before anything is signed, the monthly fee covers the named engineers, and a typical start is two to four weeks after an agreement. Your engineering leadership directs the work, and our lead handles onboarding, staffing and escalation. With 7% annual attrition, the engineers you onboard tend to stay.
Managed Java application support is the managed-services model for systems that must keep running: patching, dependency upgrades, incident response and a budget for small changes. It is a monthly retainer with a six-month minimum and then 60 days' notice, and the contract separates response times from restoration times.
For a defined result, we run a scoped project on time and materials against a written ballpark, such as the six-to-twelve-week Application Modernization Sprint. When a client asks for team extension but needs an agreed outcome rather than more people, we suggest a project instead.
We are very pleased with our partnership with Stratoflow and, as we continue to grow, we expect to increase the numbers of developers that work with us on our projects. They have proven to be very skilled and flexible.
Andrew Kennedy, Founder and Managing Director, Tier 2 Consulting
If you are weighing these models for a Java system, book a scoping call. Tell us about the team you have and the work ahead, and we will say which model fits and give you a written ballpark.