Staff augmentation, a dedicated team, or a fixed-scope project. The differences that matter are cost, control, and where the risk sits.
Pick wrong and you will feel it in month two, so this page is written to help you self-select rather than to sell you the most expensive option.
Most agencies describe all three and then recommend whichever they’d rather sell. We have a bias too, staff augmentation is the bulk of our work and the model our sourcing approach suits best, so where fixed-scope or a dedicated team is the better fit, this page says so plainly.
The six dimensions that change your experience of the engagement.
| Staff Augmentation | Dedicated Team | Fixed-Scope Project | |
|---|---|---|---|
| You manage | Yes, directly | Shared with our lead | No, we deliver |
| Best when | Clear roles, existing team | Whole workstream, no capacity | Defined scope, fixed outcome |
| Flexibility | Highest, scale monthly | Medium | Lowest, changes cost |
| Your time | Daily involvement | Weekly checkpoints | Milestone reviews |
| Risk sits with | You (delivery), us (people) | Shared | Us |
| Minimum | 1 engineer, 1 month | 3 engineers, 3 months | Per scope |
Rates differ by model as well as by role, see market rates and total cost by region. Every model is month-to-month with no exit penalty.
Engineers join your team and work the way your team already works, your standups, your board, your repos, your definition of done. You manage them directly. We handle sourcing, contracts, payroll, compliance, and replacement.
When it’s right. You have engineering leadership but not enough hands. You know what the roles are. There’s someone on your side who can review code, set priorities, and answer questions, because an augmented engineer with nobody to ask is an expensive way to produce the wrong thing.
When it isn’t. If you have no technical leadership in-house, this is the wrong model and we’ll tell you so. Augmentation amplifies an existing engineering function; it doesn’t substitute for one. Founders without a CTO usually need a dedicated team with our lead in it, or a fixed-scope build.
What typically goes wrong. Onboarding faster than you can absorb. Adding four engineers to a team of three means the existing three spend a month explaining context instead of shipping. Stage it. The second failure is a vague brief, “a React developer” describes a dozen different jobs, and the mismatch usually surfaces in week three rather than week one.
Commercials. One engineer, one month minimum. Scale up or down monthly. Covered by the 30-day replacement support per role.
A group of engineers with one of our leads embedded, owning a workstream end to end. You set direction and review outcomes at weekly checkpoints rather than managing individuals day to day.
When it’s right. There’s a workstream nobody currently owns, a mobile app, a data platform, a migration, and you don’t have the management bandwidth to run it yourself. Our lead absorbs the coordination that would otherwise land on your senior engineers.
When it isn’t. If the work is well defined and you’d rather buy the outcome, fixed-scope is cheaper and puts the delivery risk on us instead of splitting it. And if you only need one or two people, this model adds a coordination layer you’d be paying for without needing.
What typically goes wrong. Ambiguous ownership. If your team and ours both think they own architecture decisions, you get two half-designs. This needs settling in week one, in writing. The other failure is treating weekly checkpoints as status theatre, if nobody on your side reads the output, direction drifts for a month at a time.
Commercials. Three engineers and three months minimum, because a team below that size doesn’t justify the lead and a shorter term doesn’t let one form.
We agree a scope, a price, and a delivery date, then deliver against it. You review at milestones. Delivery risk sits with us.
When it’s right. The requirement is well defined and unlikely to change, a specific integration, a defined migration, a v1 with an agreed feature list. If you’d rather buy an outcome than manage a process, and you can describe the outcome precisely, this is the model that serves you best. It is also the only one where you know the total cost before you start.
When it isn’t. If the requirement is still moving, fixed-scope is the worst of the three. Every change becomes a commercial negotiation, and you will spend more time on change requests than you would have spent managing engineers directly. Discovery-stage products should not be fixed-scope.
What typically goes wrong. Scope defined in a sentence rather than a document. “A customer portal” is not a scope; it’s a category. We’d rather spend a week writing the scope properly than three months arguing about what it meant. If you won’t invest that week, choose a different model.
Commercials. Priced per scope after a written specification. Milestone-based payment. The replacement support doesn’t apply here in the same way, you’re buying a delivered outcome, so the remedy is the deliverable, not a swapped engineer.
Choose staff augmentation if you have engineering leadership but not enough hands.
Choose a dedicated team if you have a workstream nobody owns.
Choose fixed-scope if the requirement is well defined and you’d rather buy an outcome than manage a process.
Still unsure is a normal answer, and it usually means the requirement needs narrowing before the model matters. Describe the situation and we’ll tell you which of the three we’d recommend, including when the honest answer is that you should hire in-house instead.
Tell us the role and we will typically send a shortlist within 72 hours.
Tell Us the RoleDescribe the requirement and we'll tell you which of the three we'd recommend, and why.