How to Choose a White-Label Web Development Partner: The Fingerprint Test

Every white-label developer’s sales page says the same thing: your brand, not ours. We stay behind the scenes.

Then the site launches, and the client’s in-house marketer opens the page source. Or they log into WordPress for the first time. Or they google their own company and find a staging copy of their site on a domain they’ve never heard of. Now there’s a name on the work that isn’t yours.

A pitch deck can’t prove a partner is invisible. Their past work can. This post covers three things: a ten-minute audit you can run on any site a partner has built, what your client will see the first time they log in, and the questions to ask before you sign.

First, ask for a site to inspect

Ask for one live site they’ve built, or a recent staging build, to look over. A good white-label partner won’t publish a client list. That’s the job. But they should be willing to show you one build privately, under NDA if needed.

If they can’t show you anything at all, that’s a problem. If they send you a public portfolio full of other agencies’ client work, that’s a bigger one. That portfolio will include your clients one day.

The 10-minute audit

You don’t need to be a developer for any of this. You need a browser and about ten minutes.

1. Check the footer, then the source

Start with the obvious: scroll to the footer and look for “Site by…” or “Powered by…” credits.

Then right-click → View Page Source and search the page (Ctrl/Cmd + F) for:

• The partner’s company name, domain, and any abbreviation of it
• <!--, which marks HTML comments. Developers leave notes, names, and ticket numbers in these more often than you’d think.
• /wp-content/themes/. The folder name after it is the theme’s name. A theme called devshop-starter is a signature.

2. Read the theme’s stylesheet header

If the site runs WordPress, take the theme folder name from step 1 and open:

yourclientsite.com/wp-content/themes/THEME-NAME/style.css

The comment block at the top lists Theme Name, Author, and Author URI. That’s public, anyone can read it, and it’s one of the most common places a developer’s name shows up. It should say your agency, or nothing identifying at all.

3. See who WordPress says the authors are

WordPress will tell anyone who asks which usernames have published content. Try these two URLs on the site:

• yourclientsite.com/wp-json/wp/v2/users
• yourclientsite.com/?author=1

The first returns a list of users with published content, including their display names and URL slugs. The second usually redirects to an author page with the username in the URL. If you see devshop_admin or a developer’s full name, so can your client. So can anyone scanning for usernames to attack. This is a small hardening job that a careful partner does by default.

4. Check the metadata on files they delivered

Download a PDF, a hand-off document, or an image from a site they built. Open the file’s properties (on a Mac, File → Get Info or Preview → Tools → Show Inspector; on Windows, right-click → Properties → Details).

Look at Author, Creator, and Company. Word and Google Docs exports often stamp the account holder’s name into PDFs. A hand-off doc with “Author: Raj at DevShop” in its properties isn’t white-label.

5. Search for their staging sites

Staging copies of client sites are where most leaks happen. Two free checks:

• Google: search site:partnerdomain.com and scroll. Indexed staging copies of client sites on a partner’s domain show up here, sometimes with the client’s name in the title.
• Certificate logs: go to crt.sh and search the partner’s domain. Every HTTPS certificate issued for a subdomain is logged publicly. If you see clientname.staging.partnerdomain.com, you’re looking at their client list. Yours will be on it next.

Staging should live on a neutral domain, or one you control, and it should be blocked from search engines and password-protected.

How we keep staging, accounts, and hand-offs under your name: see how it works →

What your client sees when they log in

The public site is half of it. Sooner or later your client logs into WordPress, and there’s a second set of places a developer’s name tends to show up. Ask the partner for a test login on a recent build and look at:

• The admin footer. The bottom-left corner of every WordPress admin screen. Some shops replace “Thank you for creating with WordPress” with their own credit.
• Users. Usernames and email addresses on the Users screen. A developer admin account with a developer email address will outlast the project.
• Plugins. Custom plugins named after the developer (“DevShop Helper,” “DevShop Core”), and premium plugins registered to the developer’s license. When that license expires or is moved to another site, the client sees renewal notices under someone else’s name, or loses updates.
• Dashboard widgets and login screen. Branded welcome panels, support widgets, and custom login logos.
• Email. Contact-form notifications and password-reset emails that come from the developer’s domain or SMTP account.

None of these are hard to get right. They just need someone to check them on every build instead of sometimes.

The questions to ask before you sign

The audit shows you how a partner has worked. These questions tell you how they’ll work for you. For each one, here’s what a good answer sounds like.

1. Whose accounts hold the keys at hand-off?

Good answer: Hosting, domain, plugin licenses, analytics, and the code repository all transfer to accounts you own, and there’s a written list of everything that moved. Anything they keep “for convenience” is something you can’t hand to your client.

2. Where do staging sites live, and who can find them?

Good answer: On a neutral or agency-controlled domain, password-protected, blocked from indexing, and taken down after launch.

3. Will you ever contact my client directly?

Good answer: No. Every question comes through you. If a call with the client is unavoidable, they join as part of your team, under your name.

4. Do you publish a portfolio or client list?

Good answer: Not of white-label work. Case studies should be anonymized and approved by you first, or not exist.

5. How do you quote, and how fast?

Good answer: A fixed quote against a written scope, within a set turnaround (we do 48 hours), so you can quote your client without guessing at margin.

6. How will I see progress?

Good answer: Regular staging links on a set schedule, not a “big reveal” at the end. You should never have to chase a status update.

7. Who’s actually doing the work, and will it be the same people next time?

Good answer: A named team that stays with your account. A rotating bench means re-explaining your standards on every project.

8. What happens after launch?

Good answer: A defined support window, with a clear path to ongoing maintenance, and a clear answer to “what if you disappear?” The code, documentation, and access you already hold should be enough for someone else to take over.

Red flags, quickly

• Their name is in the footer, the theme header, or the users list of a site they “white-labeled”
• A public portfolio of other agencies’ client work
• Staging on their own domain, indexed by Google
• Premium plugins licensed to them “to save you money”
• They want a kickoff call with your client
• No fixed quote, only hourly estimates with no ceiling
• Vague answers about who owns the code

How we answer these

We built our process backwards from one rule: We were never here. Quotes, staging, accounts, and hand-off documents are all under your agency’s name, and we publish no client lists. See how it works →

If you’re still deciding between a studio and a solo developer, we wrote an honest comparison, including when a freelancer is the better call: White-label studio vs. freelancers →

And if the partner you’re vetting is for WordPress builds, here’s what our white-label WordPress development includes, spec sheet and all.

Frequently asked questions