Summer vacation coverage: how on-demand QA keeps releases on track while your team recharges

July is the quietest month on Slack and the loudest month on the bug tracker. Half your team is on a beach, the other half is covering two roles, and the patch still ships Thursday. On-demand QA isn’t a luxury here. It’s the only reason your roadmap survives July through September.

The summer gap nobody plans for

Every producer I’ve spoken to says the same thing in May. “We’ll figure out July closer to the time.” Then July arrives, two senior testers are in Croatia, the platform holder pushes a TRC update, and somebody on the publishing side wants a hotfix by Friday.

Summer leave isn’t a surprise. It’s a recurring, predictable, schedulable event. And yet most studios treat it like weather. Something that happens to them.

The cost of that approach is rarely visible on a single P&L line. It shows up as a delayed patch, a missed certification window, a junior QA who ran point on a release they weren’t ready for, or a senior who came back from holiday to 400 unread Jira tickets and started job hunting in October.

Why “we’ll cover internally” usually doesn’t

The internal-coverage plan tends to look fine on a spreadsheet. Six testers, two off at a time, plenty of slack. On paper, you’re fine.

In practice, it falls over for three reasons.

First, leave clusters. People take time off when their kids are off school, when their partner is off work, when flights are cheap. You don’t get a neat 20% reduction. You get a 50% reduction for two weeks in mid-August.

Second, coverage isn’t fungible. Your iOS specialist can’t suddenly run a console certification regression. Your compliance lead can’t replace the automation engineer who maintains the device matrix. Roles are specialist. Holidays don’t care.

Third, the people who stay behind get hammered. They cover their own work, plus triage, plus onboarding the new starter, plus the live ops fires. Two of them quietly resent it. One of them quietly updates LinkedIn.

What on-demand QA actually means

On-demand QA, done properly, isn’t a body-shop arrangement where you email a vendor and hope someone with a controller shows up. It’s a pre-negotiated agreement with a partner who already knows your build pipeline, your repro standards, your bug taxonomy, and your platform requirements.

The work happens in three modes:

• Scheduled burst coverage — a known sprint or release window where you bolt on 3 to 8 testers for 2 to 4 weeks.
• Standing reserve — a small allocation, maybe 0.5 to 1 FTE equivalent, that’s always warm and can scale up in 48 hours.
• Specialist gap-fill — one named tester with a specific skill (compliance, performance profiling, a particular device matrix) covering a single person’s leave.

The point of pre-negotiating is that you’re not buying capacity in July. You’re calling in capacity in July. The contract, the NDAs, the access provisioning, the onboarding doc, all of that was done in April.

The cost maths, honestly

It’s a maths problem.

Fully loaded cost of a mid-level internal tester sits somewhere around £55k to £75k in the UK, depending on benefits and overhead. That’s roughly £30 to £40 per hour, 365-day amortised. An on-demand QA partner will quote somewhere between £25 and £45 per hour depending on region, skill, and platform mix.

So the direct hourly comparison is roughly flat, sometimes cheaper. The interesting number isn’t the hourly rate. It’s the operating leverage.

Internal QA costs you the same whether you ship a patch this week or next month. On-demand costs you only the hours you actually consumed. Across a year with a heavy summer release and a quiet January, the studios I’ve worked with land at 15% to 25% lower total QA spend by blending the two models, not from cheaper hourly rates, but from not paying for idle capacity in February.

That number assumes you actually scale down when the work isn’t there. Most studios don’t. That’s a different problem.

What to lock down before July

If you’re reading this in May or June, here’s the order of operations I’d run.

Map the leave calendar first

Get every team member’s confirmed leave into one view. Not “I’m thinking about late July.” Confirmed dates. Then overlay your release calendar, certification windows, and any platform-holder events. The clashes become obvious. Usually painful.

Identify single points of failure

Who’s the only person who knows the cert submission portal password? Who’s the only one trained on your performance profiling rig? Document, cross-train, or assign external backup. Do this before they leave, not the day after.

Pre-onboard your external partner

Access provisioning takes longer than anyone expects. Source control, internal wiki, Jira, Slack, device lab VPN, NDA, IP assignment, platform dev kits. If your partner shows up August 1st and you start onboarding August 1st, you’ve lost a week.

Define what “good” looks like in writing

Bug repro standards, priority definitions, what gets escalated and to whom. Your internal team has this in their heads. Your external team needs it in a document. A 4-page playbook beats a 40-page wiki nobody reads.

Agree the comms cadence

Daily standup attendance, weekly status report, who chairs triage when the regular chair is in Greece. Boring, essential, frequently skipped.

When on-demand QA goes wrong

I’d be lying if I said this model never fails. It does. Usually for one of these reasons.

The studio treats the external team as disposable. They get the worst tasks, no context, and no feedback. Quality drops, the studio blames the partner, the partner reassigns their best people, quality drops further. Self-fulfilling prophecy.

The internal team feels threatened. If your QA leads suspect you’re using summer cover as a stealth replacement plan, they’ll withhold context, refuse to document, and generally make integration impossible. Be explicit about why the external team is there and when they’ll leave.

The scope creeps. The external team was meant to cover regression on the live build. By week three they’re being asked to write test plans for the unannounced project. Now there’s no one running regression on the live build.

Then there’s the obvious one. The partner overpromises in the SOW and underdelivers in week one. This is why you do a small paid pilot in spring, not a panic engagement in July. If you want to see how we structure pilots, our services pages lay it out.

Recharging is a release-quality issue

Here’s the part producers don’t always want to hear. Tired QA misses bugs. Not occasionally. Routinely.

A tester on their 11th consecutive day of 9-hour shifts in a hot August office, covering two absent colleagues, will let things through. They won’t mean to. They’ll just be slower at noticing the audio dropout in the third menu, the texture pop on the loading screen, the controller disconnect that only repros on a specific firmware.

Vacation isn’t a perk you grudgingly grant. It’s an input to release quality. The studios that figure this out treat coverage planning the same way they treat build infrastructure: an unglamorous fixed cost that prevents expensive failures.

What to do this week

If your summer is already underway and none of the above happened, you’ve still got moves. Triage ruthlessly, postpone what can be postponed, get an emergency engagement going with a partner who can ramp in a week, and have the honest conversation with stakeholders about which release dates are now soft.

If your summer is still six weeks out, you’ve got time to do it properly. Map the leave, pick the partner, sign the paperwork, do the onboarding, run a small pilot in July so the August scale-up isn’t anyone’s first day.

The studios that handle summer well treat coverage as a procurement problem, not a heroics problem. They’ve already had this conversation in spring. They’re not having it now.

Nobody gives a talk at GDC about the August release that shipped on time because the QA partner was onboarded in May.

“The studios that handle summer well treat coverage as a procurement problem, not a heroics problem.”