You’re about to give a stranger access to your client’s site and, whether you think about it this way or not, a share of your reputation with that client. The portfolio tells you whether they can build. It tells you almost nothing about whether they’re safe to put behind your brand.
Five questions do. Ask them before the brief, not after something breaks. How someone answers is usually more useful than the answers themselves.
1. “Will you ever contact my client directly?”
The answer is no, and it should be in writing. This is the one that ends relationships. A developer who has a channel to your client — even a friendly one, even “just to clarify something” — is a developer who can, one day, become your client’s developer. If the answer is anything softer than a flat no, stop there.
2. “Whose name is on the work?”
Not just the obvious places. Deliverables, yes — but also code comments, commit authors, file metadata, and staging URLs. All of it should be yours. A developer who leaves their name in the theme footer or the Git history hasn’t understood what white-label means, and probably won’t understand it on the parts you can’t see either.
3. “Who owns the code, and when?”
You want work-for-hire, assigned to your agency on final payment, written down. And an NDA signed before the first brief, not promised for later. This is the difference between a partner and a person who happens to be doing some work for you. If it ever ends badly, you want the code and the confidentiality already sitting with you.
4. “If it breaks for my client at 10pm on a Friday, who do I call?”
You want a name and a real answer. Not a ticket queue, not a promise to “look at it Monday.” The point of this question isn’t really the Friday night — it’s that a vague answer tells you you’ve hired a vendor, and a specific one tells you you’ve hired a partner. The two behave completely differently the first time something goes wrong.
5. “What happens when you’re full?”
The answer you want is some version of: “I’ll tell you before I take a brief I can’t deliver.” A developer who says yes to everything is a developer who will, eventually, say yes to a deadline they can’t hit — and it’ll be your deadline, in front of your client. Someone willing to say “not this month” is protecting you, even though it doesn’t feel like it in the moment.
These aren’t trick questions
A good white-label developer will have clear answers ready, probably already written down somewhere. The hesitation is the signal. Vague, improvised, or slightly offended answers to any of the five are worth more than a great portfolio, because they tell you how the relationship will actually run.
For what it’s worth, my own answers to all five are on my How I work page — with the actual NDA and services agreement there to read, not just described. If you’re weighing this up because you’ve inherited a store your team can’t service, or because a subcontractor went dark on you once, those are the exact situations this is built for.