The decision that happens before 'which vendor'
Most vendor selections that go sideways go sideways because the engagement model was wrong, not because the vendor was wrong. A senior engineering shop that is excellent at project delivery will struggle inside a team-augmentation contract, and a staff-aug shop built for embedded work will fail when handed a fixed-scope deliverable. The vendor is downstream of the model. Pick the model first.
There are three honest options. Each solves a different problem.
Staff augmentation — embedded headcount
You rent engineers who work inside your team: same repo, same standups, same PR process, same code review bar. The vendor handles employment, benefits, and replacement if someone leaves. You handle direction, prioritization, and day-to-day management.
This is the right model when the constraint is capacity, not capability. Your team knows what to build and how to build it. You just do not have enough people to build it on the timeline that matters. Staff augmentation adds velocity without adding the overhead of a parallel organization.
It is the wrong model when you need the vendor to own outcomes. Embedded engineers take direction from your team. If the direction is wrong, the output is wrong — and nobody on the vendor side is empowered to push back. An embedded senior engineer who thinks the architecture will rot in eighteen months will raise the concern once and then ship what you asked for. That is the contract.
Project delivery — outcome-accountable
You describe the outcome, the vendor scopes the work, and the vendor ships. Milestones, deliverables, acceptance criteria, and the vendor's name on the line if any of those slip. A tech lead on the vendor side owns the architecture; senior engineers own the implementation; you own acceptance.
This is the right model when the constraint is expertise, not capacity. You need something built that your team does not have the specialist depth to build well — a migration, an AI feature, a platform rebuild, a domain-specific integration. The vendor brings a pattern they have shipped before and applies it to your problem. You pay for pattern-matching at senior experience level, not for hours.
It is the wrong model when the scope is genuinely undefined. A fixed-scope contract on a problem nobody has scoped yet becomes a change-order factory — and nobody enjoys that dynamic from either side of the table. If the spec will be a conversation, not a document, staff augmentation is a cleaner shape.
In-house hire — the one you keep
You hire the engineer into your company. They learn your systems the way no vendor engineer ever will, own the long tail of decisions their code implies, and compound in value for as long as they stay.
This is the right model when the role persists past the project. If the work you are buying now will still need someone thinking about it in two years, and the economic case for the role survives the next down-quarter, hire it. The TCO of a vendor engagement over three years usually exceeds the TCO of the hire — and the institutional knowledge advantage is not close.
It is the wrong model when the need is spiky. Hiring a senior engineer for a twelve-week surge means carrying the cost for the forty weeks they are under-utilized before the next surge. Staff aug solves that problem cleanly. Do not force an engagement shape into a role shape just because the role is more familiar.
The mixed answer is usually the honest one
Real engagements rarely fit one model cleanly. The pattern we see work most often:
- One onshore senior hire for the long-lived architectural ownership.
- A project-delivery contract for the specialist piece — AI, modernization, a rewrite — where the pattern matters more than the hours.
- Staff augmentation for the sustained capacity that feeds the roadmap behind both.
The failure mode is treating the three as substitutes when they are complements. A team that buys all three functions under the same engagement shape is overpaying for two of them. A team that splits them deliberately tends to get more done per dollar than a team that consolidates.
What to ask a vendor before signing
Three questions tend to surface the misalignment early:
- What does this engagement look like if our priorities shift in week four? — staff-aug vendors should answer this easily; project-delivery vendors should flag the change-order implications honestly.
- Who is accountable if the deliverable is late? — project delivery has a clean answer; staff aug does not (because the accountability is on your side). If the answer is ambiguous, the model is wrong for the work.
- What is the offboarding path if this is not working? — the good vendors have a clean one.
The engagement model is not a procurement detail. It is the first real decision of the engagement, and the one most worth getting right before the statement of work gets drafted.
