End-to-End Test Coverage for My SaaS: Where to Start

Full test coverage for a SaaS is not one big pile of browser tests; it is layers. Many fast unit tests for business rules, a strong API layer for permissions, tenant isolation and billing, and a small end-to-end set for the five to fifteen journeys that earn money. Start with the money and data paths, gate them in CI, then widen. RAITHub builds and runs this as a managed service.

If you would rather have the suite built and kept green for you, see how RAITHub would test this below, or go straight to QA and test automation.

What does "end-to-end test coverage" really mean for a SaaS?

People ask for "end-to-end coverage" and mean "I want to be confident nothing important is broken". The mistake is to answer that with only end-to-end tests, which drive a real browser through the whole app. They are slow, they fail for flaky reasons, and a suite made entirely of them takes forty minutes and gets rerun until green. Real coverage is layered: push each check as far down as it will go, and keep only true journeys at the top.

Layer	Share (guide)	What it proves
Static checks (types, lint)	Always on	The code compiles and follows the rules
Unit	About 60–75%	Each rule computes the right answer
API and integration	About 20–30%	Endpoints, permissions and tenancy work together
End-to-end	About 5–10%, capped in the low dozens	A real user can complete the journeys that matter

The percentages are a working guide, not a standard. The full method, with ratios and a CI config, is in the test pyramid for a SaaS. Coverage as a percentage number is a weak target on its own: a missing tenant-isolation test matters far more than a coverage figure.

Where should you start on a live product?

Start where a failure costs the most the same day, not where tests are easiest to write. In order:

1. Payment and billing. Checkout, upgrade, downgrade and the webhooks that update an account. Test that a repeated event changes the account once.
2. Auth and data access. Sign-in, sessions, and whether one tenant can read or change another tenant's records.
3. The core action. The one thing your product exists to do, end to end.
4. Everything else. Widen from there, adding a test with each bug fix.

For an existing app, write characterisation tests first: tests that pin down what the app does today, so you can refactor without changing behaviour by accident. Then gate them in CI before touching any code.

Which journeys deserve an end-to-end test?

Only the ones where a failure would cost customers or money that day. For most B2B SaaS products that is a short list: sign up and land in an empty workspace; sign in and out, including SSO if you sell it; the core action; upgrade from trial to paid with a test card; invite a teammate; and export the customer's own data. Keep the total in the low dozens. If an end-to-end test is really checking a pricing rule or a validation message, move that check down to a unit or API test.

Why is the API layer the one a SaaS usually misses?

Because the bugs that hurt most live in the joins between code, database and auth: one tenant seeing another's data, a role doing what it should not, a webhook updating the wrong account. Unit tests cannot see these, and end-to-end tests are too slow to cover every combination. Run API tests against a real database (a container or a throwaway branch), and for each endpoint cover tenant isolation, the role matrix, the response contract, billing events and input abuse. A minimal isolation test:

// tests/api/tenant-isolation.spec.ts
import { test, expect } from '@playwright/test'
import { tokenFor } from './helpers'

test('a user cannot read an invoice from another tenant', async ({ request }) => {
  const token = await tokenFor('alice@tenant-a.test')
  const res = await request.get('/api/invoices/inv_tenant_b_001', {
    headers: { Authorization: 'Bearer ' + token },
  })
  expect(res.status()).toBe(404)
})

Return 404, not 403, for another tenant's record, so the response does not confirm it exists. If your SaaS runs on Supabase, this layer is where row-level security is proved; testing a Supabase app covers the data-leak checks in detail.

How do you keep the suite fast and trusted?

A slow, flaky suite is one developers learn to ignore, which is worse than no suite. Keep it trusted by:

• Running cheap layers first in CI: types and unit tests before a browser ever boots, so a quick failure stops early.
• Making each test create its own data with unique IDs, so tests do not depend on each other's leftovers.
• Stubbing third parties at the boundary (payments, email, SMS) and testing them separately in sandbox mode.
• Quarantining flaky tests, then fixing them, rather than retrying until green. Fixing flaky end-to-end tests explains the method.

The aim is a suite under about ten minutes that runs on every pull request and blocks a failing merge.

How long does it take to build this yourself?

For a small SaaS with no tests, expect about two to four weeks of one engineer's time to get static checks, a unit layer for billing and permissions, an API layer for tenant isolation, and five end-to-end journeys gated in CI. That assumes someone who knows your stack and a runner such as Vitest and Playwright. The main risk of doing it yourself is spending that time on easy unit tests while the API layer, where tenant and role bugs hide, stays empty.

Buy, build or hire?

Option	Choose this when	Watch out for
A tool or SaaS testing platform	You need a few browser checks fast and have no one to write code tests	It gives you no unit or API layer, where most SaaS bugs live
Freelancers or crowdtesting	Extra eyes before a launch	Nobody owns the suite afterwards; coverage decays
An in-house QA hire	You ship weekly, can keep one person busy and can manage QA	Slow to hire; one person rarely covers every layer
A managed QAaaS team	You want the whole pyramid built, gated and maintained for you	Make sure the tests live in your repository and you own them

Why RAITHub for SaaS test coverage?

Because RAITHub writes tests as part of every build, and the numbers are measured in real repositories: 1,024 tests on PropDesk (932 unit, 92 end-to-end, roughly ten to one), 530+ on Sundor Skin where CI replays all 76 migrations and fails if a buyer-scoped table lacks a row-level-security policy, 750+ on TheSkinProof (the founder's own venture, not a client), and 400+ on this website. The same layering is applied to an existing product, starting with the API layer where SaaS products usually have the biggest gap.

When you don't need RAITHub: if your product is pre-revenue with a handful of users, static checks, unit tests for billing and three end-to-end journeys are enough to write yourself. And if you want testers placed inside your team under your management, that is staff augmentation, which RAITHub does not offer.

How RAITHub would test this

• Scope: audit the current suite, map it against the pyramid, and rank the journeys by what they cost when they break.
• Build: add the API layer for tenant isolation, the role matrix and billing webhooks; cap and stabilise the end-to-end set; grow the unit layer with the business rules.
• Gate: wire the layers into your CI in order, cheap first, so a failing change blocks the release.
• Handover: tests and CI in your repository, a short guide to adding tests at each layer, full IP assigned to you and a standard NDA.

Buy it as a monthly QA plan, a fixed-price one-off audit, or a dedicated QA team that RAITHub manages and bills monthly. Testers are never placed under your management. Start with a free 15-minute technical audit, then a written fixed quote; no rates are published. Book the free QA audit.

Frequently asked questions

What does end-to-end test coverage for a SaaS mean?

It means layered coverage, not only browser tests: many unit tests for business rules, an API layer for permissions, tenant isolation and billing, and a small end-to-end set for the journeys that earn money. Real coverage is measured by risks covered, not by a coverage percentage.

Where should I start if I have no tests?

Start with payment and billing, then auth and data access, then the core action. Write characterisation tests to pin down current behaviour, gate them in CI, and widen from there, adding a test with each bug fix.

How many end-to-end tests does a SaaS need?

Usually five to fifteen at first: sign-up, sign-in, the core action, upgrade, invite and data export. Keep the total in the low dozens and push rule checks down to unit or API tests.

Can you add coverage to an app you did not build?

Yes. RAITHub starts with the journeys that matter most, writes characterisation tests that pin down current behaviour, and gates them in CI before widening coverage or changing any code.

Why does the API layer matter so much?

Because tenant leaks, role bugs and billing errors live in the joins between code, database and auth. Unit tests cannot see them and end-to-end tests are too slow to cover every case, so API tests against a real database are where a SaaS gets the most protection.

Will I own the tests if we stop working together?

Yes. The tests and CI configuration live in your repository, the IP is assigned to you, and the engagement runs month-to-month, so the suite keeps protecting you after it ends.