How We Handle NDA and White-Label Confidentiality

The agencies that ask the most detailed confidentiality questions before a first project aren’t the anxious ones. They’re the ones who’ve been burned before – usually not by a vendor who violated an NDA, but by one who just didn’t understand how visible they were supposed to be.

There’s a meaningful difference between a development team that technically complies with a confidentiality agreement and one that actually operates as invisible infrastructure. The first group won’t email your client without permission. The second group doesn’t think about emailing your client at all, because the question never arises.

We operate as the second type. That’s not a positioning statement – it’s just the practical result of working exclusively with agencies and building processes around that relationship for long enough that the habits are automatic.

Where the Real Risk Lives

Agencies often assume confidentiality gets settled in the contract. Sign the NDA, establish the terms, move on. That part is genuinely straightforward. What the contract doesn’t cover is workflow behavior – and that’s where the actual exposure tends to be.

A WordPress build is a useful example. The moment we get added to a client’s admin environment, there are decisions being made about what’s visible, what’s logged, and what shows up in revision history. A developer who isn’t thinking about those things will leave traces – their display name in post edits, a plugin installed without flagging it through the agency, a support ticket opened directly with a hosting provider using their own contact details. None of it intentional. All of it a problem.

We’ve taken over projects where the previous vendor’s name was still in the WordPress user list six months after the site launched. The client had seen it. Nobody had said anything. That kind of thing erodes trust in the agency, not in the vendor – because from the client’s perspective, the agency is responsible for everything.

Shopify projects create similar dynamics around collaborator access. The platform makes it easy to add external team members, but every collaborator account has a name and email attached to it. We use whatever account structure the agency designates. We don’t create a The Site Slinger collaborator entry without asking how that should be labeled.

How NDAs Work in Practice

Most agencies already have a vendor NDA. Something their legal team reviewed, used with other suppliers, and is comfortable with. We sign those without much fuss. Standard mutual protection, clear terms around what we can and can’t do with project materials, done.

If an agency is coming to us without an existing NDA template, we can draft a mutual agreement. It covers both sides in plain language and doesn’t need to be long to be effective. The goal is to have it signed before any files move – design assets, staging credentials, client-facing documentation. That’s a firm requirement.

What’s worth saying directly: we don’t claim compliance frameworks we haven’t formally verified. Some vendors will mention GDPR readiness or SOC 2 alignment in a way that sounds reassuring until someone actually asks for documentation. If a client your agency works with has specific compliance requirements, those need to be evaluated honestly at the start, not addressed through vague language in an NDA.

How Work Stays Invisible During Active Projects

All communication routes through the agency. That’s the operating assumption for every project, regardless of size or complexity.

We don’t contact end clients to ask questions. We don’t copy them on updates. If we’re working inside a shared tool where the client is also a member – a ClickUp workspace, a Basecamp project, a shared Slack channel – we operate as a background resource. Our name in that environment matches whatever the agency has set up, or we remain unnamed. The Site Slinger doesn’t need to be legible to the client.

On Figma-to-HTML work, the files come to us through the agency. We don’t request access to the client’s Figma team directly. Assets, components, prototypes – all of it arrives through whatever handoff process the agency runs with their client. That’s intentional. The fewer direct touchpoints we have with a client’s accounts, the less surface area there is for anything to go sideways.

Staging, Credentials, and Handoff

Staging environments go up under agency-owned or neutral subdomains. Not ours. When a build is ready for review, the staging link goes to the agency contact – not directly to the client. If the agency wants to share it with their client, that’s their call to make and their message to send.

Credentials for live environments – hosting accounts, CMS admin, third-party integrations – are handled through whatever secure channel the agency uses. We don’t keep copies of credentials after a project closes. If ongoing maintenance is needed, that’s a separate arrangement with explicit scope. It doesn’t carry over automatically.

One situation worth flagging: on longer projects, mid-build staging links sometimes circulate informally inside agency teams, and they end up forwarded to clients before the build is ready. We flag that when we see it coming. A client looking at a half-finished WordPress site or an incomplete Shopify storefront creates unnecessary complications – and the agency is the one who has to manage the explanation.

Handling Ambiguity Without Going Around the Agency

When something is unclear – a Figma file that’s missing mobile breakpoints, a brief that references a site redesign we haven’t seen, brand assets where nobody’s labeled which version is current – we bring the question to the agency, not to whoever created the assets.

That takes longer in some cases. It creates an extra loop that wouldn’t exist if we just made a judgment call and moved on. But judgment calls made without the agency’s input tend to produce either a wrong output or a revision conversation that should have been a brief conversation three days earlier.

This matters more than it sounds on larger builds. Frontend implementation work – whether that’s a WordPress theme, a Shopify storefront, or a Figma-to-HTML conversion – is downstream of every decision made in the design phase. If those decisions weren’t actually finalized, the development work reflects that ambiguity. Surfacing it early, through the agency, is how that gets resolved before it becomes a client-visible problem.

What Carries Over Between Projects

The first engagement with an agency usually involves the most clarifying questions – how we handle handoffs, what format we expect briefs in, how we communicate progress. That’s normal. By the third or fourth project together, most of that overhead is gone.

What changes with time isn’t just familiarity. It’s that both sides develop a shared understanding of where the boundaries are. An agency that’s worked with us for a year knows we won’t push scope without flagging it. They know we won’t open a support ticket directly with a client’s hosting provider. They know that if a client emails us – which occasionally happens, usually because an old contact was forwarded – we send it back to the agency without replying.

The confidentiality habits don’t get looser over time. If anything, the workflow gets tighter because there’s less ambiguity about how things are supposed to work.

Questions Agencies Ask Before Starting

Do you sign NDAs before files are shared? Yes. Every time. Send yours or we’ll put together a mutual agreement. Nothing moves until that’s in place.

Will you contact our clients at any point? No. All communication goes through the agency. If we’re in a shared environment alongside the client, we operate under whatever name or role the agency has assigned us – or none at all.

What happens to credentials and files after delivery? They get returned or deleted. We don’t retain access to client accounts or environments after a project closes unless a maintenance arrangement has been explicitly set up.

How do you handle it if a client contacts you directly? We route it back to the agency without responding to the client’s question. That’s the standard response regardless of what they’re asking.

What if a client asks who built their site? That’s the agency’s answer to give. We don’t need credit for the work.

What if our client has specific security or compliance requirements? Bring it up at the start. Some requirements we can accommodate directly; others may need to be evaluated against what’s actually being built. Either way, it’s better to discuss it before files are exchanged than after.

If You’re Looking for a Development Partner

The way white-label confidentiality holds up in practice is observable fairly quickly – usually within the first few weeks of a project. You’ll see it in whether questions come to you or around you. Whether staging links are handled the way you’ve asked. Whether the people building are aware that their visibility in the project is something you control.

We work with agencies on WordPress development, Shopify builds, Figma-to-HTML and PSD-to-HTML conversions, and broader frontend implementation. In all of those contexts, the approach is the same: the agency is the relationship, we’re the infrastructure.

If that model fits how your agency operates, we’re open to a conversation about a first project.