When a consultancy brings in a subcontracted engineer from a Vietnam IT company to cover a staffing gap, the single clause that causes the most friction later isn't the rate card or the SLA. It's the one that defines what that engineer is allowed to say out loud on a client call.
Consultancies resolve this along a spectrum: fully invisible (the engineer never speaks, never appears on video, sometimes doesn't even join the call), co-branded (the engineer is introduced as part of an extended team, with a shared identity disclosed), or named-but-boxed (identity disclosed, but scope of speech restricted to technical delivery only).
The decision isn't about trust in the engineer's skill. It's about who owns the client relationship, and what happens to that relationship if the subcontracting arrangement becomes visible.
TL;DR
Three operating models exist on the disclosure spectrum: fully invisible, co-branded, and named-but-boxed. Most consultancies pick based on contract risk, not engineer competence.
The governing legal instruments are the Master Service Agreement (MSA) and Non-Disclosure Agreement (NDA), typically carrying white-label provisions that prohibit subcontractor attribution, alongside work-for-hire or IP assignment clauses.
The decision usually tracks who holds the end-client relationship risk: if the consultancy's margin depends on being seen as the sole technical authority, invisibility is the default.
A subcontracted engineer's silence on branding doesn't mean silence on substance. Good white label software development practice separates "who gets credit" from "who gets heard."
Vietnam-based delivery partners that formalize this upfront, in writing, in the onboarding kit, avoid 90% of the awkward mid-project renegotiations.
About the Author: 724SOFTWARE is a Vietnam IT company that runs white-label and co-branded delivery arrangements for software consultancies and ERP/CRM implementation partners as its primary buyer segment, typically starting with a single embedded engineer and scaling toward five within a funded project. This piece draws on that operating pattern, not abstract theory.
What Does "Fully Invisible" Actually Mean in a Subcontracting Arrangement?
Fully invisible means the end client never learns that a third-party engineer touched their project. The subcontracted developer works under the consultancy's project management layer, commits code under a consultancy-owned repository identity or a generic alias, and does not appear on client calls at all. If a call is unavoidable, a consultancy-side staff member relays the technical content secondhand, or the engineer joins muted with camera off and is introduced, if at all, as "one of our engineering team."
This model exists because the consultancy is selling a single-source relationship. The client believes they are paying for the consultancy's own bench strength. If that belief depends on exclusivity, disclosure of a subcontractor undermines the premise of the engagement, not just the optics of it.
This is why the governing paperwork matters more here than anywhere else in the arrangement: the MSA and NDA between the consultancy and its delivery partner typically carry explicit white-label provisions prohibiting subcontractor attribution, while IP is secured through work-for-hire language or an outright assignment clause so there's no ambiguity about who owns what the engineer builds.
The tradeoff is real. Full invisibility works cleanly until something breaks at 2 a.m. and the client wants to talk directly to the person who wrote the code. That's the scenario every consultancy using this model needs a documented escalation path for, not an improvised one.
What Does "Co-Branded" Visibility Look Like in Practice?
Co-branded means the subcontracted engineer is disclosed, introduced by name, and positioned as part of an extended delivery team, usually described as "our partner team in Vietnam" or similar. The client knows a second company is involved. What they don't necessarily get is unrestricted access to that engineer's calendar or decision-making authority.
This model tends to show up once the relationship has matured past the first funded project. A consultancy that's scaled from one developer to four or five seats, the shape of engagement 724SOFTWARE sees most often from implementation partners, usually can't sustain full invisibility at that headcount. Too many people, too many Slack handles, too many commits for the fiction to hold.
At that point, co-branding is the more honest and more durable choice: the client gets transparency about team composition, the consultancy keeps the account-management relationship and pricing control, and the engineer gets a defined, disclosed role rather than an undisclosed one that could surface awkwardly in a support ticket.
Co-branding also changes what the engineer is allowed to say. Typically they can discuss technical implementation, answer direct questions about their own code, and join status calls as a named contributor. What they're usually still restricted from doing: discussing commercial terms, speaking to roadmap decisions that sit with the consultancy's account owner, or representing the subcontracting firm's own brand independently of the consultancy's narrative.
Why Does the Contract, Not the Engineer's Judgment, Decide What Gets Said?
Because leaving it to judgment is how disputes start. An engineer who improvises an answer about timeline, pricing, or scope on a client call, even a correct answer, can create a commitment the consultancy didn't authorize. This is a contract-drafting problem before it's a communication problem.
The practical fix is a short, explicit call-script boundary baked into the onboarding packet for every subcontracted engineer, not a general "be professional" instruction.
A workable version typically separates:
Technical scope (always answerable): bug status, architecture decisions already made, test results, sprint velocity.
Commercial scope (never answerable by the subcontractor): pricing, contract renewal, staffing changes, anything that implies a decision the consultancy hasn't made yet.
Relationship scope (answerable only if explicitly authorized per engagement): roadmap commitments, new scope requests, client complaints about the consultancy itself.
A related but distinct question is what happens when the client asks the engineer directly, "are you a subcontractor?" The honest answer, under most NDAs, is still constrained by the attribution clause. A well-drafted agreement anticipates this exact moment and gives the engineer a scripted, non-evasive response rather than forcing an improvised one on the spot.
How Should a Consultancy Decide Which Model Fits Their Deal?
The decision usually comes down to three questions, and they should be asked in this order, before the first seat is staffed, not after.
Question | If answer favors invisible | If answer favors co-branded
|
|---|---|---|
Does the client's contract with us assume sole-source delivery? | Yes, exclusivity is sold | No, multi-vendor is already normal for this client |
How many subcontracted seats will this grow to? | Staying at 1-2 | Scaling toward 5+ |
What's the cost of a disclosure surprise later? | High, relationship-ending | Manageable, already somewhat expected |
A consultancy staffing a single developer into a short fixed-scope gap can reasonably choose invisibility; the exposure is contained. A consultancy that's ramping a partner team from one engineer to five over several months, the typical shape of a funded engagement with a Vietnam-based delivery partner, usually finds invisibility collapses under its own weight somewhere around seat three. Planning for co-branding from the start avoids a messy mid-project renegotiation of the disclosure terms.
What Should Be in the Onboarding Document Before the First Call?
Three things, specifically:
A named disclosure model (invisible, co-branded, or named-but-boxed) written into the engineer's onboarding, not left to the account manager's discretion on a call-by-call basis.
A communication boundary script, covering the technical / commercial / relationship split above, reviewed with the engineer before their first client-facing interaction.
An IP and attribution clause reference, so the engineer understands, in plain terms, what they can and cannot claim credit for externally (a portfolio reference, a case study, a LinkedIn post) after the engagement ends.
This is less a legal exercise than an operational one. It's the difference between a white label IT services arrangement that scales smoothly to a five-person team and one that needs to be renegotiated every time headcount grows.
Frequently Asked Questions
Can a subcontracted engineer ever speak directly with the end client without the consultancy present?
It depends entirely on what the MSA/NDA permits. Some arrangements allow direct technical calls with a consultancy representative cc'd; others require every interaction to be routed through the consultancy's account manager.
Does white-label delivery mean the engineer's name never appears anywhere?
Not necessarily. Many white-label software development arrangements allow named technical contribution internally (in tickets, code reviews) while restricting external, client-facing attribution. The two are separate decisions.
Who owns the code the subcontracted engineer writes?
Under standard industry practice, this is handled via a work-for-hire clause or explicit IP assignment in the subcontracting agreement, which transfers ownership to the consultancy (or, further upstream, to the end client) regardless of who physically wrote it.
Is co-branding riskier for the consultancy than staying invisible?
It carries a different risk, not necessarily a greater one. Invisibility risks collapse at scale or under a disclosure surprise; co-branding risks diluting the consultancy's perceived exclusivity. The right choice depends on the client contract and the planned team size.
How quickly can a Vietnam-based partner team scale once the disclosure model is agreed?
Scaling speed depends on the delivery partner's bench and onboarding process; some partners can move from one engineer to a larger team within a few weeks once the funded scope is confirmed.
Does choosing "fully invisible" limit what kind of engineer a consultancy can staff?
No. The disclosure model is a client-facing communication decision, separate from the engineer's seniority or specialization.
About 724SOFTWARE
724SOFTWARE is a Vietnam-based IT company built around long-term delivery partnerships rather than one-off project work. The company's primary buyer segment is software consultancies and implementation partners who need embedded capacity under white-label or co-branded terms, typically starting with one engineer and scaling toward five within a funded project. With 200+ engineers (58% senior-level), ISO 9001 and ISO 27001:2022 alignment, GDPR compliance, and a follow-the-sun delivery model with sub-10-minute incident response, 724SOFTWARE builds disclosure terms, IP assignment, and communication boundaries into onboarding from day one rather than treating them as an afterthought.
If your consultancy is weighing invisible versus co-branded delivery for an upcoming engagement, talk to 724SOFTWARE at 724software.com.vn about how the contract terms should be structured before the first seat is staffed.
