Working With Subcontractors You Do Not Employ

Frame & Co sells corporate video to a regional bank. The bank thinks Frame & Co shoots, edits, and delivers everything in-house. In reality, a freelance editor named Theo, based two time zones away, does most of the cutting. Nobody is lying to anyone on purpose. The arrangement is standard in white-label production. It just means there are three layers on this project, and two of them are not internal.

The bank is the end client. Frame & Co is the agency. Theo is the subcontractor. Frame & Co can see everything — that's the point of being in the middle of your own project. But Theo, sitting in the layer directly below Frame & Co, is not supposed to know the bank's name, the contract value, or that a bank is involved at all. He gets a brief, footage, and notes. The bank, sitting above, is not supposed to know Theo exists, full stop. As far as the bank is concerned, Frame & Co does the editing.

The middle layer is the dangerous one, not the outer ones

Most access-control thinking treats "external people" as one category: outsiders, handle with the same caution. That's wrong for white-label work. The bank only ever needs a narrow, upward-facing view — status, deliverables, approvals. Theo needs a narrow, downward-facing view — the task, the files, nothing about who's paying for it. Neither of them needs to see the other. The agency is the only party that needs the full picture, because the agency is the only party carrying the liability of both relationships.

The failure mode isn't usually dramatic. It's a CC left in, a shared folder with one extra subfolder visible, an invoice line item that names the client by accident, a comment thread where someone forgot who was in the room. Once Theo sees the bank's name once, the white-label fiction is over for good. You can't partially un-know a client's identity.

What each party is actually allowed to see

• The bank (end client, guest): the deliverables and status Frame & Co grants on their own project — nothing about who else is working on it, no internal task breakdown, no cost structure.
• Frame & Co (the agency, the organisation): the full project, both relationships, every task, every conversation, in both directions.
• Theo (subcontractor, guest): the specific tasks assigned to him on a project scoped to his work — footage, notes, deadline — with no visibility into the client relationship sitting above him.

In Team and Tricks, a guest only sees what an administrator grants them — a whole project, or specific tasks inside one — and nothing else. A guest never appears in the Members list and is never assigned work the way an internal teammate is. That's the mechanism Frame & Co actually uses: the bank gets guest access scoped to a client-facing project with the deliverables and approvals on it. Theo gets guest access scoped to a separate, editing-only project with just his tasks. Each of them is a guest of the same organisation, but neither is granted anything that would reveal the other.

The part that actually holds the line is what's off by default. Seeing who else is on the team is a toggle, and it's off unless Frame & Co turns it on for a specific guest. So even if the bank and Theo were somehow granted access to the same project — which they shouldn't be — neither would see a roster that could leak the other's presence. That toggle exists per guest, not as one global switch, so Frame & Co can open it for a long-term collaborator and leave it shut for a one-off subcontractor without touching anyone else's access.

Requests keep the loop from closing by accident

Theo needs more B-roll. In a lot of tools, the instinct is to let him message "the client" directly, because that's faster. Don't. A guest can raise a request, and that request routes to the organisation's owners, admins and managers — not to another guest, not to whoever happens to be in the thread. Theo's request lands with someone at Frame & Co. The bank never sees it arrive, never sees who sent it, and never has the chance to reply straight to a subcontractor it doesn't know exists. The routing isn't a workaround Frame & Co configured; it's just where a guest request goes.

What this isn't

There is no dedicated white-label mode here, and I'm not going to pretend there is one. What there is: project- and task-scoped guest grants, roster visibility that's off unless you turn it on per guest, and request routing that never hands a guest another guest's address. Frame & Co builds the isolation by structuring two separate projects and granting each guest only their own — the same tools any admin has, used deliberately instead of by default. It takes one more decision at setup: don't put the bank and Theo on the same project, even though it would be slightly more convenient to run the whole job from one board.

That decision is the whole job, honestly. Permissions software doesn't know which of your external people are supposed to know about each other. It only enforces whatever boundary you draw. Draw it once, correctly, at the project level, and the three-layer arrangement holds itself — Theo keeps editing footage for a client he'll never meet, the bank keeps believing Frame & Co did it all, and the only person who ever sees the whole shape of the job is the one who's supposed to.

A subcontractor is not a teammate with fewer checkboxes, and an end client granted a guest view is not the same kind of guest as the subcontractor underneath them, even though the product offers both the identical mechanism. The mechanism is neutral. What it's isolating is not.