Clients often ask for the wrong one of these, and the mismatch usually surfaces two months in as a complaint about velocity or communication that is really a complaint about ownership.
Extend the team when you own the direction
Augmentation works when you have a technical lead with the context, a backlog someone is actively shaping, and a definition of done that already exists. The constraint you are solving is capacity, not judgement. Engineers join your standups, your repository and your review process, and the accountability for what gets built stays with you.
It fails when it is used to cover an absent technical lead. Engineers without context ask questions; if nobody has the answers, they either stall or guess, and both are expensive.
Outsource the project when you own the outcome but not the path
Project delivery works when you can describe the result and the constraints — what it must do, who it serves, when it must launch, what it must integrate with — and you would rather not staff the path to get there. Scoping, architecture, delivery and the tradeoffs along the way sit with us, and we carry the risk of the estimate.
It fails when the requirements are genuinely unknown at the start. That is not a reason to avoid it; it is a reason to buy a short discovery phase first and treat the output as the input to a real estimate.
The hybrid that usually works
In practice the common arrangement is a delivered first phase followed by an embedded team for the second. We build and launch the thing, then one or two of the engineers who built it stay on inside your process while your own hires ramp.
The handover is the part to get contractual. Documentation, infrastructure access, a working local environment and a fortnight of overlap — written into the engagement, not negotiated at the end of it.
