Verification matters more in white label arrangements than in ordinary vendor selection, because your client will never see the people doing the work. If the team is not what it claims, you will be the one explaining it.
The difficulty is that the usual signals are weak. Portfolios can include work the team only partly touched. Reviews can be solicited, incentivised, or written about a different service. Case studies are written by the company they flatter. None of this means a provider is dishonest, but it does mean the easy checks do not tell you much.
Verify the work, not the portfolio
A portfolio image proves a site exists. It does not prove who built it. There are a few cheap checks that get closer.
- Visit the live sites rather than the screenshots. Sites in a portfolio are sometimes long gone, redesigned by someone else, or were never live at all.
- Look at page source for the actual stack. If a portfolio claims custom development and every site is a stock theme with a page builder, that is a real discrepancy worth raising.
- Run one or two through a public performance tool. You are not looking for perfection, you are checking whether the claims about performance work survive contact with evidence.
- Ask which parts of a given project they did. Honest answers frequently include "we did the build, not the design" — that is a good sign, not a bad one.
The most revealing question is simply: can I speak to the agency you built this for? A partner running a genuine white label practice may reasonably decline on confidentiality grounds, which is itself consistent. But they should be able to offer some reference, even an anonymised one.
Check that the company exists in the way it implies
Basic and often skipped. Look up the registered entity in the relevant companies register, check how long it has traded, and confirm the trading name matches the legal one you will be contracting with. A mismatch is not automatically a problem — plenty of legitimate businesses trade under a different name — but you should know who you are actually contracting with before you sign.
Check where the team is. Not because location determines quality, but because it determines overlap hours, and an arrangement that depends on same-day responses across a twelve-hour gap needs to be designed for that rather than discovered.
Verify the people, briefly
You are not running background checks. You are confirming that the team described in the proposal resembles the team that exists. Public professional profiles, public code contributions, conference talks or written technical content all help. A company claiming a fifteen-person engineering team with no discoverable engineers is worth a question.
Ask directly who would work on your projects and whether that is stable. The honest answer is often that it depends on availability, which is fine — what matters then is whether conventions and documentation make the output consistent regardless of who is assigned.
Test the technical claim, cheaply
The most efficient verification is a short technical conversation about something specific and awkward from your own recent work. Not a quiz — a real problem you have already solved or failed to solve.
What you are listening for is whether they ask clarifying questions before answering, whether they identify the trade-offs rather than declaring one right answer, and whether they are willing to say a requirement is a bad idea. A partner who agrees with everything in a sales conversation will agree with everything during delivery too, which is how projects end up technically wrong but contractually compliant.
Ask how they use AI tooling and where they do not. The specific version of that answer is hard to fake and tells you how the work actually gets done. Our own split between where AI helps and where engineers stay accountable is one example of what a concrete answer looks like.
Check reviews for shape, not score
A five-star average across generic praise is less informative than a four-star average where the reviews describe specific projects, name specific problems, and mention how those were handled. Look for reviews that mention something going wrong — how a company behaves when a project is difficult is the thing you actually want to know.
Be appropriately sceptical of clusters: several reviews posted in the same week, similar phrasing, or reviewers with no other history. And weight recency heavily. A team's quality two years ago tells you little if the people have changed.
The verification that actually works
Everything above reduces risk. None of it eliminates it, because the thing you are trying to predict — how this team behaves on a real project with a real deadline — cannot be observed from outside.
The only reliable test is a small paid project. Choose something with a genuine deadline and at least one awkward requirement, and watch the things a proposal cannot show you: whether the estimate held, whether you heard about problems early, what the handover documentation actually contains, and whether the quality checks they described happened. A clean brief with a soft deadline tests nothing.
If you want to see what a partner's finished work looks like before committing to that, our recent client work is live rather than screenshotted, and what partnering with us involves sets out how a first project is scoped so that being wrong about us stays inexpensive.
