A 12-person SaaS company might have eight developers, one product manager, and no dedicated QA engineer.
At first, testing is manageable. Developers check their own changes, somebody clicks through the important workflows before release, and production issues get fixed as they appear.
Then the product grows.
Login now has SSO. Billing has several plans. Users have different permissions. Integrations fail in ways that are hard to reproduce. Releases happen several times per week. Developers start skipping parts of regression because checking everything manually takes too long.
You can run a SaaS product without a dedicated QA department. You cannot run it for long without assigning the work QA normally owns.
That work includes defining expected behaviour, identifying risk, building regression coverage, investigating failures, and deciding whether a release is safe.
Here are five practical ways small SaaS teams handle it.
Quick comparison
ApproachSoftware costInternal effortSpeed to startGood fit whenMain riskDevelopers test manuallyVery lowVery highImmediateProduct is still smallRegression gets skipped as the product growsBuild Playwright/Cypress internallyLowHighMediumStrong engineering team wants full controlMaintenance becomes another engineering responsibilityUse AI/coding agents for testingLow–mediumMediumFastClaude/Codex already drive developmentGenerated tests can validate the wrong assumptionsUse a self-service AI testing platformLow–mediumLow–mediumFastWeb regression is the main problemBusiness-critical coverage still needs reviewUse managed AI testingHigherLowMediumNobody has capacity to operate testingRequires clear scope and provider accountability
1. Let developers own manual testing
This is how many early SaaS products start.
A developer implements a feature, checks it locally, gets a PR review, and manually tests the main workflow before release.
For a small product with ten important flows, this can work.
The problem appears when regression starts expanding faster than the team.
Consider a permissions change. The developer needs to verify that:
- an admin can assign a role;
- the user receives the new permissions;
- restricted areas remain unavailable;
- removing the role removes access;
- existing roles still work.
The feature itself may take a few hours to build. Verifying everything affected by it can take another hour.
Multiply that across several developers and several releases per week.
Manual developer testing has no software bill, but it consumes expensive engineering capacity.
It also has a structural weakness: the person who interpreted the requirement and wrote the implementation is often testing the same interpretation.
Works well: very early products and low-risk internal applications.
Starts breaking down: frequent releases, multiple roles, integrations, billing, or dozens of regression workflows.
2. Build your own automation with Playwright or Cypress
The traditional next step is code-based automation.
For a web SaaS product, Playwright is currently one of the strongest options. Tests live in your repository, run in CI, and can be reviewed like normal code.
AI has made this approach significantly easier.
Playwright now ships planner, generator, and healer agents. The planner explores the application and produces a test plan, the generator creates executable Playwright tests, and the healer investigates failing tests and attempts repairs. Playwright provides agent configurations for Claude Code, Codex, VS Code, and OpenCode.
A team can run a workflow such as:
Feature specification → test plan → generated Playwright tests → CI → failure investigation
The software itself is open source.
The cost is the people operating it.
The U.S. Bureau of Labor Statistics reports a 2025 median annual wage of $104,300 for software QA analysts and testers and $135,980 for software developers.
That is roughly $8,700 or $11,300 of monthly salary respectively before benefits and overhead. You may only spend 20–30% of one person's time on automation, but that time still has a cost.
Your team also owns fixtures, authentication, test data, CI, flaky tests, coverage strategy, agent instructions, and maintenance.
Works well: engineering teams with automation experience that want complete control.
Risk: a “free” testing stack slowly becomes an internal platform somebody has to maintain.
3. Let coding agents create and maintain tests
This model is growing quickly as development itself becomes agentic.
A developer working in Claude Code or Codex can now ask an agent to create tests alongside the feature, execute them, inspect failures, and make changes.
Playwright's own testing agents already support this workflow. QA Wolf also supports developer workflows where agentic tests run on pull requests, while teams can choose between self-service automation and its managed service.
This removes a lot of repetitive test-writing work.
It does not guarantee good coverage.
Imagine an account-deletion feature whose requirement says:
Only organization owners can permanently delete an account.
The implementation accidentally allows admins as well.
If the coding agent interprets the product from the implementation rather than a reliable requirement, it may generate a perfectly passing test confirming the incorrect behaviour.
Useful controls include clear acceptance criteria, negative scenarios, independent test review, and evidence that shows what actually happened during execution.
Works well: teams already using coding agents heavily and willing to keep quality decisions inside engineering.
Risk: faster generation of tests can create faster false confidence if coverage is not reviewed.
4. Use a self-service AI testing platform
A self-service testing platform reduces the amount of automation infrastructure the team needs to own.
This is useful when the problem is mainly web regression rather than a need for a complete QA organization.
A typical B2B SaaS application might automate:
- login and authentication;
- onboarding;
- user creation;
- permissions;
- billing;
- forms;
- CRUD operations;
- admin workflows.
Treegress Platform is one example of this model. It is a separate self-service web E2E product starting at $49/month. Its current plans are designed around automated browser testing without requiring the customer to maintain an automation framework.
For a small SaaS team, this can be significantly easier than setting up Playwright infrastructure just to protect 20–30 critical workflows.
The team still needs to identify the behaviours that matter.
A testing platform can automate execution and reduce maintenance, but product knowledge remains important. A billing workflow that technically completes successfully can still be wrong if tax rules, permissions, or plan logic are incorrect.
Works well: web SaaS products that need repeatable regression quickly.
Risk: treating automated coverage as complete simply because the tests pass.
5. Use managed AI testing instead of building an internal automation function
Sometimes the bottleneck is operational capacity.
The team may already know what should be tested but have nobody available to:
- choose and configure the testing stack;
- extend coverage;
- investigate failures;
- keep automation current;
- evaluate new testing agents;
- maintain environments and test data.
Managed testing moves more of that operational work outside the engineering team.
QA Wolf's managed service, for example, includes application mapping, Playwright/Appium automation, infrastructure, maintenance, failure investigation, and a dedicated QA team. Its pricing is based on the tests it manages rather than engineering hours.
MuukTest follows a similar managed model. It says its service starts at $5,000/month for up to 1,000 tests under management, and it can work alongside an existing internal QA team.
Treegress Managed AI Testing is a separate offer from Treegress Platform. It creates a product-specific setup using the tools appropriate for that product, which can include existing tests, open-source frameworks, specialized AI agents, Treegress capabilities, and approved third-party tools. Treegress then operates the agreed workflow, reviews failures, and maintains the setup.
As of September 30, 2026, Treegress lists a 30-day pilot at $1,499 one-time, covering up to three agreed workflows; the regular pilot price is $5,000. Ongoing service starts at $2,499/month.
Works well: teams whose biggest constraint is QA or engineering capacity rather than access to another testing tool.
Risk: unclear scope. Define who owns coverage decisions, failure investigation, test maintenance, integrations, and changes in product behaviour before signing.
When should you actually hire QA?
Automation does not remove the need for QA expertise.
A dedicated QA person becomes more valuable when exploratory testing matters, workflows have many combinations and edge cases, mobile/device coverage grows, customer defects require regular investigation, or developers spend too much time deciding what should be tested.
The first QA hire also does not have to be an automation engineer.
A strong product-aware QA specialist can own risk, exploratory testing, requirements review, and coverage decisions while automation or AI handles much of the repetitive execution.
What should a 10–20 person SaaS team do?
For a typical web SaaS company with 8–15 engineers, 0–1 QA people, weekly releases, and 20–50 important workflows, a practical sequence is:
- Identify the 10–20 workflows whose failure would materially affect customers or revenue.
- Put those workflows under deterministic automated regression first.
- Run them automatically before releases or in CI.
- Use AI to accelerate test planning, creation, maintenance, and investigation.
- Keep human review around requirements, risk, negative scenarios, and important behavioural changes.
- Track how much developer time testing still consumes. Add QA capacity or managed testing when investigation and maintenance become the bottleneck.
Do not start by trying to automate every screen.
Start with workflows such as signup, authentication, permissions, billing, core CRUD operations, and the actions customers use to get value from the product.
Can AI replace a QA team?
For some small SaaS companies, AI and automation can delay the need for a dedicated QA department.
They do not eliminate the quality function.
Someone still needs to define correct behaviour, decide what risk matters, review uncertain results, and investigate cases where product behaviour and requirements disagree.
Can developers own QA permanently?
Some engineering-led companies do.
It tends to work when automated regression is strong, quality is treated as part of development rather than a final phase, and developers have enough capacity to maintain the system.
If regression repeatedly delays releases or production bugs are being discovered by customers, that model needs additional support.
What should be automated first?
Start with stable, high-value workflows that are repeatedly checked before releases.
Authentication, permissions, onboarding, billing, primary CRUD flows, and critical integrations usually provide more value than automating every cosmetic interaction.
Bottom line
Running SaaS without a dedicated QA department is possible.
Running it without a clear quality operating model is much harder.
Small teams can keep testing manual for a while, own Playwright internally, use coding agents, adopt a self-service testing platform, or move some of the operation to a managed provider.
The useful metric is how much reliable coverage you get for the total engineering and QA effort required to maintain it.
As the product grows, revisit that calculation. The testing model that works for six engineers and twenty workflows may be completely wrong a year later.
