In-house QA vs outsourced QA: how to decide which one you need

The way this question usually gets asked — in-house or outsourced — implies two options at the same price point and an answer that is a number. It is neither. An in-house tester and an external QA team fail in different directions, and the failure you can least afford is the thing that should decide it.

We are an external supplier, so the bias here is obvious. What follows is the reasoning we actually use when someone asks, including the cases where the honest answer is that they should hire.

The question behind the question

Quality is not a role. It is a set of activities: deciding what is worth testing, executing it, judging whether a release is safe to ship, and keeping the paths that already work from breaking. A team can distribute those activities in many ways. "Should we hire a tester" collapses all of them into a headcount decision, which is how you end up with a capable person spending their first six months writing test cases nobody reads.

The more useful question is which of those activities your team is currently doing badly, and whether the cause is capacity, skill, or the fact that nobody owns it. Those three have different solutions, and only one of them is a job advert.

A capacity problem and an ownership problem look identical from a distance. Only one of them is solved by adding a person.

What an in-house QA hire actually costs

The salary is the part everyone models correctly. These are the parts that tend to be missing from the spreadsheet:

• Lead time. Finding a QA engineer takes weeks, and their notice period takes more. If the release that worries you is this quarter, a hire does not address it — the person arrives after the thing you were afraid of has already happened.
• Ramp. A tester is useful in proportion to how well they understand the product. The first month is reading, asking and shadowing, and that cost is paid again every time someone leaves.
• Utilisation. Testing demand is not flat. It spikes in the days before a release and collapses after one. A single in-house tester is either the bottleneck in release week or under-occupied for the rest of the sprint, and usually both in the same month.
• Breadth. One person brings one background. If they are strong on exploratory testing and the problem you hit next is a slow, flaky automation suite, you have the wrong specialist and no quick way to change that.
• Concentration. Everything that person learns about how the product really behaves lives in one head. It walks out with them.

None of this is an argument against hiring. It is an argument against hiring as the reflex first move, before anyone has established which activity is actually broken.

Where an external team wins

• Start date. An external team starts in weeks rather than quarters, which matters when the trigger is a deadline rather than a plan.
• Elasticity. Capacity can follow the release calendar instead of averaging it. Two people through a hardening phase, one between them, is a shape an employment contract cannot take.
• Specialisms under one contract. Manual test design, automation engineering and security assessment are three different skills, and very few individuals are strong at all three. Buying them separately as headcount is expensive; buying them as a service is normal.
• Written-down knowledge. An external team has no choice but to document what it learns — test plans, regression checklists, reproduction steps — because it cannot rely on hallway context. That documentation is the deliverable, and it stays with you.
• An outside read on the process. A supplier who has seen thirty release processes will notice that yours has no defined exit criteria. An internal hire inherits the process as a given.

Where outsourcing goes wrong

It fails in predictable ways, and almost all of them are visible before the contract is signed.

• Nobody on your side owns the answers. Testers generate questions continuously — is this a defect or intended, does this edge case matter, is this data realistic. Without someone empowered to answer them quickly, an external team stalls, and you pay for the stalling.
• The build gets thrown over a wall. If the only interface is a deployed environment and a bug tracker, you will get defect reports and no improvement in how the product is built.
• You buy execution when the problem is design. If the test cases themselves are the weak point, more hands executing them faster produces more confident wrongness.
• The contract measures the wrong thing. Test cases executed is a volume metric. Risk covered is the one you care about, and the two diverge quickly once someone is optimising for the first.
• The distance is real. Time-zone overlap, language and legal jurisdiction change the day-to-day more than the rate does — which is the whole argument for nearshore over offshore.

The answer most teams land on

In practice the durable arrangement is rarely one or the other. It is one internal person who owns quality decisions — what ships, what blocks, what the standard is — supported by an external team that supplies capacity and specialisms against that standard.

That split works because it puts each side where its structural advantage is. Judgement about your product needs to sit with someone who lives in it. Executing a regression pass across six browsers, or building an automation framework that survives its first year, does not.

It also fails gracefully. If the external engagement ends, the standard and the documentation remain. If the internal owner leaves, the external team can hold the line while you replace them. Neither single-point failure takes the whole function down.

A decision you can make in an afternoon

Five questions, in order. The first one you answer honestly usually settles it.

1. 01Is the pressure a date or a pattern? A date argues for an external team, because hiring cannot arrive in time. A pattern — quality that has been drifting for a year — argues for someone who will still be there next year.
2. 02Does anyone currently decide what "ready to release" means? If not, that is an ownership gap, and no amount of outsourced execution closes it.
3. 03How much does testing your product depend on domain knowledge? Clinical workflows, settlement rules and insurance pricing take months to learn. A booking flow or a checkout does not.
4. 04Is the work continuous or bursty? Look at the last six months of releases rather than the plan for the next six. Some sectors are structurally bursty and never flatten out.
5. 05What happens to what you have learned when the arrangement ends? If the answer is "it disappears", you have chosen the wrong shape, whichever side of the line it sits on.

If the answers point at an external team, the follow-up question is which one, and that is a separate exercise — what such engagements look like in practice is a more useful thing to interrogate than a rate card.