1. What a subcontractor NDA should cover
The aim is simple: the developer must not disclose or reuse what they learn about you and your client. A useful NDA states this clearly instead of leaving it to goodwill.
- What counts as confidential: client identity, designs, content, credentials, business information, the existence of the project itself.
- What the developer may use it for: only the agreed work.
- Who is bound: the developer and anyone they involve, which should be agreed in advance.
- How long the obligation lasts, including after the project ends.
- What happens to materials at the end: return or deletion.
- Exceptions that are normal, such as information that is already public.
2. White-label specifics
In a white-label setup, two extra points are worth writing down. First, the developer does not contact the end client, unless you ask them to. Second, the developer does not show the project in a portfolio, or mention the client, without permission.
This is how my own portfolio handles confidential work: projects under NDA appear without the client name, the URL, screenshots or branding. If you want a case study published, it is agreed with you first. I sign an NDA if the agency or the end client asks for one.
3. Access hygiene during the project
Most security problems in a subcontracted project come from access, not from bad intentions. Keep access narrow and traceable.
- Work on staging. Give production access only if the task needs it, and for the shortest time possible.
- Create a named account for the developer instead of sharing your own login.
- Give the lowest role that lets them do the job.
- Share credentials through a password manager, not through chat or email.
- Keep the list of who has access to what, and update it when the work changes.
4. The handover checklist
At the end of the project, collect these before the final payment, while the developer still has context.
- The code, in a repository or as a package, with a note on how it is structured.
- A short note on how to update content without touching the design, including any custom fields.
- The list of plugins and themes, with versions and who holds each licence.
- Deployment and update steps, including any build process.
- Known issues and decisions that are not obvious from the code.
- A staging site that behaves like production before launch.
- Backups taken before launch and a note on where they are stored.
5. Close the access at the end
After handover, remove the developer's accounts, rotate any shared credentials and revoke repository and hosting access. If the developer will do maintenance later, give access again for that work rather than leaving it open.
Ask the developer to delete or return project materials as agreed in the NDA, and to confirm in writing.
6. A short version to keep
Before: NDA signed, scope written, staging ready, named accounts created. During: lowest access, credentials in a password manager, no contact with the end client unless agreed. After: handover collected, accounts removed, materials returned or deleted, confirmation received.
Frequently asked questions
Should the NDA come from the agency or the developer?
Either. Many agencies have their own template, and it is usually easier for the developer to sign what you already use with other suppliers. If the end client also requires one, say so at the start.
Is an NDA enough to protect the client?
It is one layer. Narrow access, a named account, work on staging and a clear handover do as much in practice as the document does on paper.
Can the developer show the project in their portfolio?
Only if you agree. For white-label work the default should be that they do not, and that any case study is approved by you first.
Next step
Need extra WordPress capacity under your own brand?
The service page explains what I take on, what stays outside the scope and how a first project starts.
See how the partnership works