Skip to content
All articles
Outsourcing

Staff augmentation, dedicated team, or fixed scope? How to choose

Three ways to work with an outside engineering partner, what each one is good at, and five questions that tell you which model fits your project.

Microverge Engineering2 min read

When a company decides to bring in outside engineers, the first question is usually "who?" The better first question is "how?" The engagement model decides who owns the outcome, how you pay, and how much of your own time the work will take. Pick the wrong one and even a great team will feel like a bad fit.

There are three common models. Here's what each one actually means, where it works, and where it doesn't.

1. Staff augmentation: more hands on your team

You add individual engineers to your existing team. They join your standups, use your tools, and take direction from your engineering manager. You own the plan and the outcome; the partner supplies skilled people.

  • Works best when you already have strong technical leadership and a clear backlog, and you're short on capacity or a specific skill.
  • Watch out for: it doesn't fix a planning or leadership gap. If your team doesn't know what to build next, adding people makes the problem more expensive, not smaller.

2. Dedicated team: a unit that owns a workstream

The partner provides a small cross-functional team — engineers, often QA and design, plus a delivery lead — that owns a product area or roadmap. You set priorities; they handle planning, delivery, and reporting.

  • Works best for ongoing product work where priorities change every few weeks and you want a team that keeps context over time.
  • Watch out for: you still need a product owner on your side who can make decisions quickly. A dedicated team waiting on answers is the most expensive kind of idle.

3. Fixed scope: a defined outcome at a fixed price

You agree on what will be delivered, by when, and for how much. The partner carries the delivery risk. This is the classic model for an MVP, a migration, or a well-defined internal tool.

  • Works best when the scope is genuinely known — or when a short, paid discovery phase can pin it down first.
  • Watch out for: changing requirements mid-project. Every change becomes a change request, which is slow for both sides. If you expect to learn and pivot a lot, a dedicated team is usually a better fit.

Five questions that point to the right model

  1. 1Do you have an engineering lead with time to manage more people? If yes, staff augmentation is an option. If no, look at a dedicated team or fixed scope.
  2. 2Can you write down what "done" looks like today? If yes, fixed scope can work. If not, start with discovery or a dedicated team.
  3. 3How often do priorities change? Monthly or more often points to a dedicated team.
  4. 4Is this a one-off or ongoing? One-off projects suit fixed scope; ongoing products suit a team that stays.
  5. 5Who should carry the delivery risk? Fixed scope moves it to the partner; the other two keep more of it with you.

You can switch models

Many good partnerships change shape over time. A common path is a fixed-scope MVP, followed by a dedicated team to iterate on it, and later a smaller retainer to run and maintain it. Ask any partner you're evaluating whether they support that path, and how handover works between stages.