There is no universal QA-to-developer ratio that tells a SaaS team whether quality is covered. The useful question is how much uncertainty the team carries into each release, and what the impact is when something important fails.
Start with product risk, not headcount.
QA demand increases when workflows are business-critical, changes touch connected areas, releases are frequent, defects are expensive to recover from, or the team lacks reliable regression coverage. A small product with payments, permissions and complex state can need more deliberate QA than a larger but simpler application.
Separate exploration from protection.
Exploratory testing helps discover where the product is fragile. Regression testing protects known important behaviour. Automation is most useful after stable, repeatable journeys have earned a place in that regression layer.
The sequence matters. Automating before understanding the product can create a large suite that protects the wrong things.
Signals that you may need more QA.
- Releases depend on developers remembering what to retest.
- The same areas break repeatedly after unrelated changes.
- Important bugs are found by customers before the team sees them.
- No one can explain what the current regression scope protects.
- Automation exists, but the team does not trust its signal.
A practical starting point.
For a team without clear QA ownership, a focused risk review is often more useful than starting with a large QA engagement. It creates an evidence-based view of critical journeys, current weaknesses and what deserves repeatable protection next.