You have three proposals open in browser tabs, two portfolios that look almost identical, and a client launch that will not move. Every outsourcing partner says they are reliable, communicative and careful. None of that helps you decide, because nobody ever writes “we miss deadlines” on their homepage.
Choosing well is less about finding the most impressive team and more about finding out, cheaply and early, how a team behaves when things are not going to plan. This guide walks through the questions that separate partners, the warning signs worth acting on, and a way to trial someone before your client’s site depends on them.
Start by writing down what you are actually outsourcing
Agencies often go shopping for “a WordPress partner” when what they need is narrower. Before you contact anyone, spend twenty minutes listing the work you expect to hand over in the next six months. Be concrete:
- New builds from your own designs, or edits to sites you built years ago?
- Small fixes that arrive unpredictably, or planned projects with deadlines?
- Ongoing care of live client sites, including updates and backups?
- WooCommerce stores, membership sites, or mostly brochure sites?
- Work on builders such as Elementor, or custom themes and blocks?
This list does two jobs. It lets you ask each candidate about the work you will really send, rather than the work they like to show. And it tells you whether you need a partner at all, or simply someone to absorb a busy quarter. If you are weighing those options against each other, our comparison of a partner, a freelancer or a new hire sets out the trade-offs.
Questions that reveal how a partner works
Most discovery calls stay on capabilities. Capabilities are the easy part. What decides whether a partnership survives is process, and process only shows when you ask about specifics. These are the questions worth putting to every candidate, ideally in writing so you can compare answers side by side.
On estimates and scope
- “If I send you a brief today, what do I get back before any work starts?” You want to hear about a written scope, an estimate and the assumptions behind it.
- “What happens when you find the job is bigger than you estimated?” A good answer involves stopping and telling you, not quietly absorbing it or quietly billing it.
- “How do you handle a change my client asks for halfway through?” Listen for a clear line between the agreed scope and new work.
On safety with live sites
- “Do you take a backup before changing a live site, and where is it stored?”
- “When do you use staging, and what do you do when a host does not offer it?”
- “How do you test a plugin update before it reaches production?”
On communication
- “Who will I actually talk to, and is it the person doing the work?”
- “What do your notes look like at the end of a job?” Ask to see an anonymised example.
- “How do you tell me something has gone wrong?” The honest answer is usually “straight away, with what we know so far”, and it is worth hearing them say it.
On confidentiality and your client relationship
- “Will you ever contact my client directly?” The only acceptable answer for a white-label arrangement is no, unless you ask them to.
- “What branding, credits or footer links do you leave on a site?”
- “Will you sign an NDA, and what happens to access and files when we stop working together?” The post on what an outsourcing agreement should cover gives you a list of points to raise.
Pay attention to how the answers arrive as much as to what they say. A partner who replies with a vague paragraph to a specific question will probably reply to your bug reports the same way.
Red flags worth taking seriously
Some warning signs are obvious, such as asking for full payment upfront for a large project with no scope. Others are quieter and easier to excuse during a friendly call. These are the ones agencies tend to regret ignoring:
- Yes to everything. If a team agrees to every deadline and every technology without a single question, they have either not read the brief or are not planning to tell you about problems until late.
- No questions about the client’s site. A careful developer wants to know the host, the theme, the plugins and what has broken before. Silence here usually means assumptions later.
- Portfolio without context. A gallery of homepages tells you about design taste, not about who did what. Ask which parts of a project they built and what was hard about it.
- Unclear about who does the work. If the person you speak to cannot say who will write the code, the work may be passed on again.
- Reluctance to put things in writing. Scope, change rules and confidentiality should all be easy to write down. If they resist, ask why.
- Requests for more access than the job needs. A one-page fix rarely needs your hosting reseller login.
We have collected more of these, with a focus on hiring help from other countries, in a separate piece on warning signs when hiring offshore developers.
Check the boring details before you sign
The difference between a pleasant partner and a dependable one usually lives in details nobody enjoys discussing. Settle these before the first real job:
- Where the code lives. Your repository, your client’s hosting, or the partner’s own environment? Decide now, so nothing important sits only on someone else’s laptop.
- How access is shared. Individual user accounts with the right role are better than a shared admin password passed around in chat.
- How invoicing works. Per job, per hour, or a monthly block? Whichever it is, you should be able to predict the next invoice.
- What a “finished” job includes. Testing on mobile, a note of what changed, cleanup of any temporary plugins or accounts.
- How payment works across borders. If the partner is abroad, confirm the method early. Many teams use PayPal or Wise; agree on currency and timing so nobody is surprised.
Run a trial that tells you something
A trial project is the most reliable way to judge a partner, but only if it is designed to reveal how they work. A trial that is too easy proves nothing. One that is too big puts a client at risk before you know who you are dealing with.
Pick something real, small and slightly awkward. Good candidates include:
- A layout bug on mobile that your team has not had time to chase.
- A plugin update that you suspect will conflict with something.
- A single template change on a builder site, with a clear before and after.
Pay for it. Unpaid tests attract the wrong partners and put the good ones off. Our guide to setting up a small paid test project covers how to size it and what to write in the brief.
What to watch during the trial
The result matters, but the route to it matters more. Keep notes on:
- Did they ask questions before starting, and were the questions sensible?
- Did the estimate match the outcome, and if not, did they warn you?
- Did they take a backup, or work on a copy, before touching anything?
- Was the handover note clear enough to forward to a colleague who knows nothing about the job?
- Did anything unexpected change on the site, such as a plugin quietly updated or a setting reset?
A trial that goes slightly wrong can be more useful than one that goes perfectly. You learn how a partner reports a problem, which is the thing you most need to know.
Score the candidates the same way
After calls and a trial, impressions blur. A simple scoring sheet keeps the decision honest. Rate each candidate on the same handful of points, using your notes rather than memory:
| Area | What a strong answer looks like |
|---|---|
| Scoping | Written scope and assumptions before work begins; asks about the site first |
| Safety | Backup or staging every time, with a clear plan when neither is easy |
| Communication | Plain updates, problems raised early, notes you could forward |
| Confidentiality | No contact with your clients, no credits on sites, willing to sign an NDA |
| Fit | Comfortable with the specific work on your six-month list |
| Practicalities | Invoicing and payment you can plan around; access handled with care |
Do not average the scores. A partner who is excellent at building but weak on safety is a bad fit for live client sites, however good the average looks.
Start narrow, then widen
Even after a good trial, resist the urge to hand over your whole workload in week one. Start with one client or one type of work. Give it a few jobs. Then widen the scope as you build a shared sense of how briefs, approvals and handovers run.
During that period, review the first few jobs before they reach your client, even if it slows you down. A short internal check catches misunderstandings while they are still cheap. Over time you will know which kinds of work you can pass straight through and which still need your eye.
It also helps to agree on one way of briefing work from the start. A partner can only be as precise as the instructions they receive, and a consistent format saves both sides from guesswork. Our guide to briefing outsourced developers clearly includes a template worth borrowing.
A short checklist to keep
- Six-month list of work written before contacting anyone
- The same written questions sent to every candidate
- Red flags noted, not explained away
- Code location, access, invoicing and “done” agreed in writing
- A small, real, paid trial with notes on process as well as result
- Candidates scored on the same points, with safety treated as a must-have
- First jobs limited in scope and reviewed before the client sees them
None of this makes a perfect match certain, but it moves the surprises to a stage where they cost you a small trial instead of a client. For a wider view of how agencies set up this kind of arrangement, our guide to WordPress outsourcing for agencies brings the pieces together.
If you would like to put us through the same questions, our page on development work delivered under your agency’s name explains how we scope and hand over, and we are happy to start with a small trial.
Next in this series: White-Label Partner vs Freelancer vs Hire: Agency Guide
