The fear every agency principal names out loud is poaching: the subcontractor takes the call, quotes direct, and the account you spent three years building walks. It is a real risk and it is worth papering against. It is also not what usually happens. What usually happens is quieter, takes about six weeks, and leaves no clause you could have invoked. Your client's trust does not get stolen. It migrates — slowly, and toward whoever answers the hard question first.
Authority moves at the speed of the answer. Watch the mechanism rather than the motive. On a Tuesday call your client asks something specific: why the nightly import takes four hours now, whether the API change lands before their board meeting, what the fallback is if the model provider rate-limits you at launch. You do not know. You say you will find out. You message your delivery partner, wait for their morning, and come back on Wednesday with a summary you cannot defend under a follow-up question — because the reasoning behind it happened in a thread you were not in. Do that three times and your client has learned something without being told: you are a slower path to the same information. The fourth question goes straight to the engineer, and everyone will feel it was reasonable.
Nobody behaved badly in that sequence. The structure produced it. And the structure is common because of who owns the client relationship at most agencies: the person who sold the work. The US Bureau of Labor Statistics counts 454,800 jobs in the occupation that covers much of that role, projects it to grow 6 percent between 2025 and 2035 with about 36,300 openings a year, and describes the work as planning "programs to generate interest in products or services" (US Bureau of Labor Statistics, Advertising, Promotions, and Marketing Managers, Occupational Outlook Handbook, employment 2025, projections 2025–35). Nothing in that description covers defending a schema decision to a sceptical CTO, and it should not have to. This is not a criticism of account leads; it is a staffing fact with a direct consequence. If the only person on your side of the table is the person who sold it, subcontracting will cost you the technical relationship by default, because there is nobody on your payroll who can hold it.
So the first thing to buy back is a named technical owner of your own. One person, on your side, per engagement, whose job is to answer at one level below the surface. They do not write the code. They read the pull requests rather than the summaries of the pull requests. They attend one working session a week with their camera on. They can draw the architecture on a whiteboard, say why the queue is there, and describe what happens at ten times the traffic. That is genuine cost — hours you cannot bill at full rate, on an engagement whose margin is the reason you subcontracted. Pay it anyway, because the alternative is paying for capacity and quietly selling the relationship. If you have no one senior enough in house, that role is exactly the shape of a fractional CTO: a part-time technical owner is far cheaper than an account that leaves.
The incident is where the relationship is actually decided. Everything above is survivable on a normal week. The week the production system falls over is the week your client forms a permanent opinion about who is in charge, and the failure mode is well documented. In its chapter on managing incidents, Google's Site Reliability Engineering team describes what an unmanaged response looks like from the outside: "Nobody knew what actions their coworkers were taking. Business leaders were angry, customers were frustrated, and other engineers who could have lent a hand in debugging or fixing the issue weren't used effectively" (Google, Managing Incidents, Site Reliability Engineering, chapter 14). Their remedy is to assign roles before anyone needs them, on the principle that "It's important to make sure that everybody involved in the incident knows their role and doesn't stray onto someone else's turf" — and one of those roles exists purely for the outside world. Of the person handling communication, the chapter says: "This person is the public face of the incident response task force."
Read that as an instruction about your engagement and it writes itself. In a white-label build there are two organisations in the room during an outage, each with a plausible claim to be running it, and no agreed answer about who speaks to the client. Settle it on a calm Tuesday instead. Your subcontractor leads the operational work, because they are the only people who should be touching the system. Someone on your side is the public face, issuing the updates on your letterhead at a stated cadence, even when the update is that there is nothing new. The temptation in hour three is to put the engineer who is fixing it on the client call, because that is faster. It is faster, and it is the single most expensive shortcut available to you: it teaches your client, under maximum emotional load, that the real team is somebody else.
Now the honest cost of the opposite extreme, because an article that only told you to route everything through yourself would be selling you something. Insulating the people building from the people using is not free, and it is not a neutral choice. Google's DORA programme lists customer feedback among the capabilities that predict software delivery and organisational performance, and names the failure directly: "Gathering feedback too late. Sometimes companies gather customer feedback so late in the software delivery lifecycle that they cannot act on it," alongside "Failing to allow teams to act on feedback" — because "Delivery teams must be empowered to make changes to the design or specification of the system in response to feedback" (Google, Capabilities: Customer feedback, DORA). The same page puts a number on why this matters more than it sounds: citing industry data from A/B testing, it reports that in successful products "only about one-third of proposed features improve business outcomes when actually delivered. The remaining two-thirds of features deliver zero or negative outcomes for businesses."
If two out of three features are duds even when the builders can see the users, consider the hit rate when every observation reaches them third-hand, a week late, filtered through an account manager's notes. A strict no-contact rule protects the relationship and degrades the product, and a degraded product costs you the relationship anyway — just later, and with a worse story. The resolution is not a rule about who may speak. It is that contact happens under your name, with you in the room, and its output lands in your tracker rather than in a private thread. Put the engineer on the discovery call, introduced as your team, and take the notes yourself. You are controlling the record and the framing, not the flow of information — the flow of information is the thing you are being paid to have got right.
Everything the client can see has to be in one voice, and it is more surface than you think. Status notes, release notes, pull request descriptions if they have repository access, the postmortem after the outage, the deck at the quarterly review. Register bleeds. A team that writes terse one-line updates reads differently from one that writes paragraphs, and a client who has read your prose for two years will notice the change before they can name it. So decide the written register once, at kickoff, and hold the update format steady — what to ask for in a weekly update is the format itself, and it works identically whether your own engineers or a partner's filled it in. Watch the accidental tells too — timezone stamps, a licence header, a bot posting under an unfamiliar organisation. None is a betrayal; each is a surprise your client did not sign up for.
There are three things you must be able to do without anyone from the delivery team present. Demo the product, end to end, on a laptop, on a bad hotel connection. Explain one layer below the interface — why this data store, why this model, what breaks first under load. And answer the question your client will eventually ask in some form: what happens to us if you disappear. Fail one of those and you have a gap to close. Fail all three and you are a reseller, and the client will work it out in a room you are not in. Rehearse them before a renewal conversation, because the renewal turns on whether the client believes you own the thing, not on whether the tickets closed.
The cost nobody writes down is that the capability does not accrue to you. Every build teaches somebody something, and by default that somebody is your subcontractor. Three years of this and your bench cannot build what your website sells; your estimates drift because you no longer feel the work; the partner knows your client's system better than anyone you employ. That is a slow, structural version of the poaching risk, and no non-solicit touches it. It has mitigations, all of which cost margin. Rotate one of your own engineers through each build, even if they are the slowest person on it. Require design documents, written before the code, living in your repository. Or decide deliberately that you are a firm that sells delivery rather than a firm that builds, and price accordingly. All three are defensible. Drifting into the last one without noticing is not.
And plan for the day they find out, because sometimes they do — a commit email, a LinkedIn profile, an unfamiliar voice on a bridge call. The answer has to exist in writing before you need it, and it has to be true: yes, part of this build is delivered by a partner working under our name; they are bound by our confidentiality and non-solicitation terms; the code and the IP are ours and therefore yours; the person accountable for it is me. Clients accept that answer far more often than principals expect, because it is how most professional services work. Denial is the version that ends relationships. The paperwork that makes the answer true rather than aspirational is a separate piece of work — what belongs in a white-label subcontract covers the clauses, and they need to be signed before anyone has repository access, not at final invoice.
The thing that actually keeps a client is not a clause and not concealment. It is being the party who decides. A client leaves for a subcontractor when the agency has become a pass-through — when every technical question, every roadmap trade-off and every estimate is really being answered somewhere else and relayed. They do not leave because they once met an engineer whose email address was different. That is the honest case for choosing a white label software development partner whose business is repeat agency work, and it is also the honest limit of what any partner can promise you: we can sign your terms, stay invisible, and refuse the direct call, but we cannot hold the relationship on your behalf. That part is not delegable.
One test, at the end of every engagement, before you sign the next one. Could you run next quarter's planning conversation with this client alone — no one from the delivery team in the room, no lifeline — and commit to a scope and a date you would stand behind? If yes, subcontracting bought you leverage and the margin is real. If no, you did not buy capacity; you rented a relationship that used to be yours. Where the capability is defined and the date is fixed, a scoped sprint is often the cleaner shape, precisely because it ends — and an arrangement you can end is one you are still choosing.
Find this useful? Tell Google to show you more of it.