The two data points, side by side
| Source | Typical threshold | How it's measured |
|---|---|---|
| ContextQA | 15-25 developers | Traditional ratio of ~1 QA engineer per 3-5 developers |
| Pragmatic Engineer | 20-50 total people | Practitioner-reported, broader denominator (whole company, not just engineering) |
The two don't fully agree, and that's worth stating plainly rather than picking one and presenting it as settled — different denominators (developers vs. total headcount) and different sourcing (industry ratio vs. practitioner reporting) explain most of the gap. What both agree on: it's a double-digit-developer or higher threshold, not something most teams below 15 developers should expect to reach soon.
Dedicated QA is rarer than most founders assume, even later
The more important, less obvious finding is what Pragmatic Engineer adds beyond the raw threshold: the absence of dedicated QA isn't just an early-stage-startup phenomenon. Mid-sized companies of 150-600 people frequently have none, and most teams at large technology companies have no dedicated QA role at all, with rare, notable exceptions. If your team has no dedicated tester today, you're not behind some industry norm — you're in the large, normal population of teams that test some other way, by necessity or by choice.
What "some other way" actually means before you hit the threshold
Below the 15-25 developer / 20-50 person range, teams generally land on one of three approaches, each with a real trade-off:
- Developers test their own and each other's work manually. No new cost, but it's the arrangement most directly linked to the Katalon-reported barriers of insufficient time (55%) and high workload (44%) — see the hidden cost of manual QA testing for the fuller picture.
- Someone builds test automation in-house. Durable, but it consumes real engineering time up front and ongoing maintenance time after — effectively spending the same scarce developer-hours the team is already short on.
- A tool generates and runs structured test coverage from the requirements you already write. This is the option that doesn't require either a new hire or a dedicated automation engineer — see how to test your product without a dedicated QA team for what that looks like in practice.
A reasonable way to think about timing
Rather than fixating on a single headcount number, it's more useful to track two things: how much developer time manual testing is consuming right now (worked out concretely in how much manual QA testing really costs a small dev team), and how often a regression slips through because coverage got thin under deadline pressure. When either of those is rising faster than headcount, that's the real signal it's time to act — whether that action is a hire, in-house automation, or a lighter-weight tool, well before the 15-25 developer mark if the pain is already there.
Frequently asked questions
When should a startup hire its first QA engineer?
Industry staffing guidance places the typical threshold at 15-25 developers, based on a traditional ratio of roughly one QA engineer per 3-5 developers. A separate practitioner analysis puts it a little later, around 20-50 total employees. Below that, most teams test manually or lean on developers, not because it's ideal, but because a dedicated QA hire usually isn't justifiable yet.
Do all companies eventually hire dedicated QA staff?
No. Practitioner reporting indicates that mid-sized companies of 150-600 people frequently have no dedicated QA function at all, and most teams at large technology companies have no dedicated QA role, with rare exceptions. The absence of dedicated QA is common well beyond the early-stage-startup phase.