How to Set Up QA for an Early-Stage SaaS With No QA Team

With no QA team, the developers own quality, and you start with what makes money or holds data: sign-up, login, the core action, billing and who can see what. Add CI gates in order, type-checks and unit tests first, then integration tests on a real database, then a few end-to-end journeys, and let any failure block the merge.

This is the setup guide for a SaaS with one to five developers and no testers. It does not repeat two related posts: how RAITHub tests software describes RAITHub's full test pyramid and release gates, and the pre-launch QA checklist is what to check in the week before a launch. This post is about building the habit from nothing, in the order a small team can afford.

Who owns QA when there is no QA team?

The developer who writes a change also writes its tests, and the pipeline enforces it. Quality assurance (QA) here means the practices that stop bugs reaching users, not a separate department. At this stage, it has three owners:

• The developer writes the tests for their change, in the same pull request.
• The reviewer checks that the tests cover the risky part, not just that they exist.
• The pipeline blocks any merge where a check fails. This is the owner that never gets tired or busy.

The founder's job is to protect that rule under deadline pressure. The moment "we'll add tests later" is accepted once, it becomes the default.

What should an early-stage SaaS test first?

Rank by what it costs you when it breaks, not by what is easiest to test. For most SaaS products the order below holds; adjust it to your product's money and data paths.

Priority	What to test	Why first	Best test level
1	Tenant and permission boundaries: user A cannot read or change user B's data	A leak is a trust and legal problem, not a bug	Integration tests against the API
2	Billing: plan changes, webhooks, failed payments	Errors cost money directly and are hard to repair afterwards	Unit tests for the rules; integration tests for webhook handling
3	Sign-up and login	If nobody can get in, nothing else matters	One or two end-to-end journeys
4	The core action your customers pay for	The reason the product exists	One end-to-end journey, plus unit tests for its rules
5	Data writes: create, update, delete on your main records	Silent data loss is found late and costs the most	Integration tests on a real database
6	Everything else	Added as bugs are found, one regression test per bug	The lowest level that reproduces it

Row 5 deserves a real example. On this website in September 2026, every check was green while zod 4's .partial() re-applied default values to partial updates, which would have unpublished records and wiped fields on a simple reorder. It was caught in review, and the fix added a regression test for every update schema, 19 tests in all (the write-up). A test that asserts "a partial update changes only the fields sent" is cheap; the bug it prevents is not.

Which CI gates should you add, and in what order?

One gate at a time, fastest first, each blocking the merge before you add the next. A small team can have all of these working within a month.

When	Gate	What it catches	Typical run time
Week 1	Type-check and lint	Wrong data shapes, renamed fields, obvious mistakes	Seconds to a minute
Week 1	Unit tests	Pricing, validation and permission rules	Under a minute
Week 2	Integration tests on a real database	Queries, migrations, transactions, tenant filters	A few minutes
Week 3	A clean migration replay on an empty database	Migrations that only work on a developer's existing data	About a minute
Week 4	End-to-end journeys in one browser	A user journey that no longer completes	A few minutes for a handful of tests
Later	Performance budgets, more browsers, contract tests	Slow pages, browser-specific bugs, API shape changes	Grows with the product

The run times are rough guides for a small product, not benchmarks. What matters is that the whole pipeline stays fast enough that nobody is tempted to skip it; ten minutes is a sensible ceiling for a pull request.

This order follows the test pyramid: write tests at different levels of granularity, and the more high-level the test, the fewer of them you should have (The Practical Test Pyramid, martinfowler.com). End-to-end tests are the most expensive to run and to keep stable, so they come last and stay few.

What does a minimal CI pipeline look like?

One workflow that installs from the lockfile, starts a real database, and runs every gate in order. This example is GitHub Actions for a Node.js and PostgreSQL app; the script names are placeholders for your own.

# .github/workflows/ci.yml
name: ci
on:
  pull_request:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_PASSWORD: postgres
        ports: ['5432:5432']
        options: >-
          --health-cmd pg_isready
          --health-interval 5s
          --health-timeout 5s
          --health-retries 10
    env:
      DATABASE_URL: postgresql://postgres:postgres@localhost:5432/postgres
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npx tsc --noEmit
      - run: npm run lint
      - run: npm run db:migrate        # replays every migration on an empty database
      - run: npm test                  # unit and integration tests
      - run: npx playwright install --with-deps chromium
      - run: npx playwright test --project=chromium

The pipeline only protects you if it can block a merge. In GitHub, add a branch protection rule on main with required status checks, so a pull request cannot be merged until those checks succeed (GitHub: about protected branches). npm ci matters too: it installs exactly what the lockfile says and fails if the lockfile and package.json disagree (npm ci documentation). The Playwright step assumes a webServer entry in playwright.config.ts that starts the app.

How many tests does an early-stage SaaS need?

Enough to cover the six priorities above, then roughly one or more tests per feature and one regression test per bug. The count follows the product; it is not a target. As a rough guide, and RAITHub's guidance rather than an industry benchmark:

• First paying customers: dozens of unit tests on business rules, integration tests on every tenant-scoped endpoint, and three to five end-to-end journeys.
• A year of features later: hundreds of tests, still mostly unit and integration, with end-to-end journeys in the low tens.

Counts from platforms RAITHub built show where steady habits lead. They grew with the features, not in a push at the end:

Platform	What it is	Automated tests
PropDesk	Property management with Stripe rent collection and 4 roles	1,024
TheSkinProof	The founder's own marketplace venture, not a client project: 217 API endpoints and 5 portals	750+
This website	Marketing site, admin and content management	400+

A useful signal is not the number but the trend: if features ship and the count does not move, tests are being skipped.

What should you not test yet?

Anything that changes weekly or cannot hurt you. Testing it now is effort you will throw away.

• Pixel-level layout of pages still being redesigned. Test that the journey completes, not how it looks.
• Every browser. Start with one engine; add others when your analytics show real users on them.
• Third-party services end to end. Mock them in end-to-end tests and test your integration code separately.
• Load testing before you have load. A basic performance budget on key pages is enough for now.
• Trivial code such as getters and configuration objects. Coverage on those proves nothing.

How do you keep the suite trusted as it grows?

Keep it fast and keep it honest. A slow suite gets skipped, and a flaky one gets ignored.

• Treat a flaky test as a bug with an owner, and quarantine it with a time limit rather than re-running until green. The guide to flaky end-to-end tests covers how.
• Write a regression test with every bug fix, one that fails on the old code and passes on the new.
• Push tests down the pyramid. If an end-to-end test is really checking a rule, move it to a unit test.
• Watch the pipeline time. When it passes ten minutes, parallelise or move tests down before anyone starts skipping it.

For picking the end-to-end tool itself, see Playwright vs Cypress in 2026.

When should you hire a dedicated QA engineer?

When the testing work is real but nobody owns it: releases slip because regression checking takes days, customers find bugs your suite should have caught, or the product has enough roles, integrations or regulated data that someone needs to think about risk full time. Until then, a developer-owned suite with CI gates covers most of what an early-stage product needs. A QA engineer's first job should be improving that suite, not replacing it with manual checks.

Why RAITHub for this, and when you don't need us

RAITHub builds every product QA-first: a real test suite with CI gates is included in every engagement, and every layer blocks the release. The counts above are from that practice. The QA and test automation service sets this up for an existing SaaS: ranking your risks, writing the first tests where they matter, building the pipeline and branch protection, and handing it over so your developers keep it going. RAITHub publishes no rates; the quote is fixed and written after a free 15-minute technical audit, and IP in all work is yours.

You don't need RAITHub if:

• Your developers can follow this plan and have the time. It is written so that a small team can.
• You have no product yet. Build the first version with tests from day one; there is nothing to retrofit.
• You want manual testers clicking through the app. RAITHub builds automated suites gated in CI, and does not place testers in your team.
• You need a certified vendor for a compliance requirement. RAITHub is not SOC 2 or ISO 27001 certified.

To get a first suite and CI gates in place, book the free 15-minute technical audit.

Documentation checked on 29 September 2026.

Frequently asked questions

How do you do QA without a QA team?

Make developers write tests with every change, have reviewers check that the risky part is covered, and let the CI pipeline block any merge where a check fails. Start with permissions, billing, login and the core action.

What should a startup test first?

Tenant and permission boundaries, then billing, then sign-up and login, then the core action customers pay for, then writes to your main records. Everything else gets a regression test when a bug is found.

How many tests should an early-stage SaaS have?

Enough to cover the critical paths, then one or more per feature and one per bug. At first customers that is typically dozens of unit tests, integration tests on tenant-scoped endpoints and three to five end-to-end journeys. The count should grow with the features.

Which CI checks should block a merge?

Type-checks, lint, unit tests, integration tests on a real database, a clean migration replay and a few end-to-end journeys. Add them one at a time and make each one required before adding the next.

Should a startup use end-to-end tests?

Yes, but only a few, for the journeys that make money: sign-up, login, the core action and payment. Most checks belong in faster unit and integration tests.

When should a startup hire a QA engineer?

When regression checking delays releases, customers keep finding bugs the suite should catch, or the product's roles and integrations need someone thinking about risk full time.