Sales calls with a prospective outsourcing partner all sound much the same. Everyone tests carefully, communicates clearly and respects deadlines. You cannot tell the difference between them from a conversation, and you should not have to. The quickest way to find out how a developer really works is to give them a small, real job, pay for it, and watch what happens.
A paid test task is not about catching anyone out. It is a low-stakes way for both sides to see whether working together suits them before your clients are involved. Done well, it tells you more in a short engagement than months of guessing. Done badly, it tells you almost nothing. This post covers how to pick the task, run it and judge the result.
Why the test should be paid
Some agencies ask for a free sample first. It is understandable, and it usually backfires.
- Free work gets treated as marketing. A developer doing unpaid work either rushes it or polishes it far beyond what normal work would get. Neither shows you their ordinary standard, which is the thing you need to see.
- Good developers often decline. Those with steady work have little reason to do unpaid jobs, so a free test filters out some of the people you most want.
- Paying sets up the real relationship. You see how they estimate, how they invoice and how they handle the payment route. Those are part of the working relationship too.
- It keeps things clean. If the test work ends up on a client site, it should be paid for and properly licensed, with no question about who owns it.
Treat the test as a normal, small job at normal terms. That is also what makes it a fair test.
Choosing the right task
The ideal test task is real, small and slightly awkward. Real, because invented exercises do not show how a developer handles an actual site with all its quirks. Small, because you want a result quickly and with little risk. Slightly awkward, because a task with no judgement involved only tells you whether someone can follow steps.
Good candidates
- A bug that has been sitting on one of your own or a friendly client’s sites, with a known symptom but an unknown cause.
- Building one new section or template from a design, on a staging copy.
- Updating plugins on a staging copy of a site that has a fragile plugin or two, and reporting what changed.
- A small performance review of one page: what is slowing it, what they would change and what they would leave alone.
- Tidying up a contact form that sends unreliably, including confirming where the email goes.
Poor candidates
- Anything on a live store’s checkout or a site where downtime costs real money. The test should not put a client at risk.
- Work for a pitch you have not won. That is speculative work, and it puts the developer in an unfair position.
- A large project split into a “first phase.” If the first phase goes wrong, you are already committed.
- A task so simple anyone could do it. Changing a heading tells you nothing about how they think.
- Sites with sensitive customer data unless you have agreements and access rules in place first.
Using a staging copy for the test is ideal. If you do not have one set up, our explainer on what a WordPress staging site is and how to use one covers the basics.
Running the test like a normal job
The test is only useful if it mirrors how real work would flow. Do not give extra hand-holding, and do not hold back information you would normally share.
- Write a proper brief. Use the same format you would for any job. If you do not have one yet, the test is a good reason to create it; there is a fill-in template in our guide to briefing outsourced developers.
- Ask for an estimate before work starts. Note what they ask before giving it.
- Give access the way you would for real work: a named user with a suitable role, sent through your normal private route.
- Use your normal channels. If routine questions go by email and urgent ones by WhatsApp, say so and see whether they follow it.
- Leave them to it. Avoid checking in constantly. You want to see what they communicate unprompted.
- Review the result with your normal process. The checklist in reviewing outsourced work before it reaches a client works for a test as well as for live jobs.
- Have a short debrief afterwards, ideally a call: what went well, what you would change.
What to judge, beyond “did it work”
The finished result matters, but it is only one part of what a test reveals. Score each of these, even informally:
| What to watch | Good sign | Worrying sign |
|---|---|---|
| Questions before starting | Specific, batched, about things the brief missed | None at all, or questions the brief already answered |
| Estimate | Explained, with assumptions stated | A single number with no reasoning |
| Safety habits | Mentions backup or staging without being asked | Changes the live site without a word |
| Updates during the work | Short, clear, flag anything blocking | Silence until “done,” or constant small pings |
| Scope discipline | Notes other problems but asks before fixing | Changes things outside the brief |
| Delivery notes | What changed, what was tested, what was not | “Done, please check” |
| Estimate against actual | Close, or explained early when it changed | Overrun mentioned only on the invoice |
| Response to feedback | Fixes the point, retests, says what was retested | Defensive, or fixes one thing and breaks another |
Pay close attention to the “what was not tested” part of the notes. A developer who is honest about the limits of their own checking is one whose “tested, all fine” you can later believe.
Plant one small question
A useful technique is to leave one genuine ambiguity in the brief: a detail you have not decided, such as which of two buttons the new section should link to. You are not trying to trick anyone. You want to see whether they notice it and ask, or guess silently. Asking is what you want from someone who will work on your clients’ sites while you are offline.
One test is not enough for everything
A single small job shows you working habits, communication and honesty. It does not show you how a partner handles pressure, a large build or a genuine emergency. If the first test goes well, consider a second, slightly larger job before handing over anything important, and pay attention to whether the standard holds once the novelty has worn off.
Be fair in the other direction too. A test with a confusing brief, slow answers from your side or access that did not work will produce a poor result that says more about the setup than the developer. If something on your end slowed them down, take that into account.
What to tell the developer up front
Be open that this is a trial. Something like:
“We would like to start with one small paid job to see how we work together before we pass you client work. It is a real task on a staging copy, briefed the way we brief everything. Afterwards we will have a short call about how it went, from both sides.”
Being honest about it removes the guesswork for them and usually brings out their normal way of working, which is exactly what you want to see. And invite their feedback on your brief and process. You are being tested as a client as well.
Mistakes that spoil a test
- Testing several partners on the same task at once. It seems efficient, but you end up comparing finished results and skipping the communication, which is where partners differ most. If you must compare, give each a different real task and judge the process.
- Judging speed above everything. A fast delivery with no notes and an untested form is worse than a slower one you can trust. Speed matters, but only once the basics are right.
- Forgetting to remove access afterwards. Whatever the result, take back the access the test needed, or confirm it is still needed for the next job.
- Letting the test drift into free extras. If you ask for “just one more thing” during the test, either add it to the estimate or leave it for a later job. Otherwise you are measuring generosity, not work.
- Not writing anything down. Keep a few lines on what you saw while it is fresh. When you are deciding a few weeks later, memory will have smoothed over the details that mattered.
After the test
Decide quickly and say clearly. If it went well, agree the next job and the working rules you want to keep. If it did not, say so politely and pay promptly. If you are unsure, say what you would need to see in a second test.
A paid test also sits alongside the other checks covered in warning signs when hiring offshore help, and helps you choose between models such as a partner team, a freelancer or an employee, which we compare in white-label partner, freelancer or in-house hire. All of it is part of building a sound approach to outsourcing WordPress work for your agency.
A single bug fix is often the right size for a first job with any new partner. If you would like to try one with us, our bug fixing service for agencies’ client sites is a natural place to start.
Next in this series: Agency Client Offboarding: Ending a Client Cleanly
