21 October 20258 min read
Subcontracting has a slightly furtive reputation in agency work, which is odd, because almost every agency of any size does it. Construction firms subcontract, law firms use counsel, production companies hire crews. Nobody thinks less of them for it. The discomfort in digital services comes from a specific worry: that the client believes they are buying your people, and would feel misled to learn otherwise.
That worry is worth taking seriously, but it is a disclosure problem, not an argument against subcontracting. The real question is when subcontracting genuinely serves the work, and what to put in place so that the predictable failures do not happen.
The cases where it clearly makes sense
Four situations account for most sensible subcontracting.
- A demand spike you believe is temporary. Two large projects land in the same quarter. Hiring against a spike leaves you with people and no work six months later; subcontracting matches the cost to the revenue.
- A capability you need occasionally but not continuously. Mobile, data engineering, accessibility remediation, a second language for support. Not enough volume to justify a permanent hire, too much to refuse.
- Coverage outside your own working day, where the client wants support or monitoring hours your team does not work.
- A pipeline you cannot forecast, where the alternative to a capacity partner is either turning work away or carrying bench cost through the quiet months.
In all four the logic is the same: the demand is real, and the shape of it does not fit permanent headcount. That is what a delivery partner is for.
The cases where it does not
Subcontracting is the wrong answer when the thing you are actually short of is direction rather than hands. If nobody on your side can specify the work, review it, or say what done means, adding capacity produces more output and no more progress. The output will be blamed on the partner, and the partner will not be the problem.
It is also wrong when the capability is the one you are selling. An agency that positions itself on a specific craft and subcontracts that craft is buying a short-term margin at the cost of the thing it charges for. Subcontract around your differentiator, not through it.
And it is wrong when the work is a rescue of a system nobody understands. Discovery is the expensive part of a rescue, and if a partner does it, you pay for the discovery without acquiring the understanding, which leaves you no better able to serve that client next year.
The five failure modes, and where each is decided
Subcontracted delivery goes wrong in a small number of ways, and each of them is decided long before anyone notices the symptom.
The margin is set at the wrong price. Decided at the quote. You sold a fixed scope on your own estimate and bought delivery on someone else's, and the difference between the two estimates is your margin. If you did not have the partner estimate before quoting, you did not price the job; you guessed at it.
The client discovers the arrangement in a way that feels like a reveal. Decided at the sales conversation, not at the moment of discovery. Almost no client objects to a delivery partner when told plainly at the start. Nearly all of them object to finding out from a signature block eight weeks in.
Quality drifts and you find out from the client. Decided when you set up review. If the only person checking the work is the person paying for it, you have outsourced quality control to your own client, which is the single most expensive thing on this list.
The partner and the client start talking directly and you gradually stop being necessary. Decided in the contract and in your own habits. This is the disintermediation risk, and it has a clause and a working pattern that address it.
The partnership ends mid-project. Decided in the exit terms, which almost nobody negotiates because both parties are optimistic at signing. Who holds the repository, the credentials, the documentation and the client's data on the day this stops is a question that costs nothing to answer at the start.
How to structure the arrangement
There are two workable shapes, and mixing them is where trouble starts.
In staff augmentation, you buy named people for a period, they work inside your process, your standards and your definition of done, and you direct them. You carry the delivery risk because you are the one managing the work. It fits when your process is good and what you lack is people.
In managed delivery, you buy an outcome against a statement of work. The partner brings its own lead, its own process and its own quality control, and is accountable for the result. It fits when you do not have management capacity to spare, and it costs more per hour because the partner is carrying more.
The failure is buying managed delivery prices, taking staff augmentation control, and expecting the accountability of the first with the interference of the second. Decide which one you are buying and write it at the top of the agreement.
The overlap question
If you are directing the work yourself, the partner's working hours matter more than their rate. Every ambiguity in a specification becomes a question, and a question that waits until tomorrow to be answered costs a day of someone's time and a piece of your project manager's attention. This is the time-zone tax, and on a directed engagement it is paid daily.
This is why European agencies mostly end up with partners within a couple of hours of their own day rather than the cheapest available rate. A partner in Beirut, an hour or two ahead of Western Europe, shares an entire working afternoon with Berlin, Paris or Amsterdam, which means a question asked at eleven is answered before lunch. On managed delivery with clean acceptance criteria, a wider gap is survivable. On directed work it is not.
What to have before the first sprint
You do not need a hundred pages. You need the partner's written estimate and assumptions, the shape of the arrangement stated plainly, a definition of done that both sides have read, a named lead on each side, an agreed review step that happens on your side before anything reaches the client, and an exit clause covering repositories, credentials, documentation and data. If you have those six, subcontracting is an ordinary commercial decision. Without them it is a bet on everybody staying happy, which is not a plan.