SaaS Pre-Launch QA

108 tests stand between your SaaS and a launch-day disaster

One cross-tenant leak, one billing miscalculation, one broken checkout — and trust is gone before support even opens a ticket. Here is the full pre-launch checklist, organized into 8 domains, that catches it first.

108Pre-launch tests

8QA domains

$2.41TUS cost of poor software quality

32%Customers who leave after one bad experience

Why bother

The economics of skipping QA

Defects don't stay cheap. The later a bug is caught in the lifecycle, the more it costs — in engineering hours, churn, and reputation.

$2.41T Estimated cost of poor software quality across the US economy in a single year. SOURCE: CISQ, 2022

$1.52T Of that, accumulated technical debt sitting unresolved in production systems. SOURCE: CISQ, 2022

+650% Increase in failures traced to weak open-source components between 2020–2021. SOURCE: INDUSTRY DATA, 2020–21

13.5 hrs Spent weekly, per developer, servicing technical debt instead of shipping — roughly a third of the workweek. SOURCE: INDUSTRY SURVEY

The core four

Where launch-blocking bugs actually hide

Tests 1–60 cover the domains where a single miss is existential: tenant data leaking across accounts, revenue silently miscalculated, an attacker escalating privilege, or the API buckling under real load.

DOMAIN 01

Multi-Tenant Architecture & Data Isolation

Tests 1–15

Objective: protect tenant boundaries — no customer should ever see another's data, on purpose or by accident.

Row-level security policy enforcement

Cross-tenant object authorization checks

Cache & search-index namespace isolation

Background worker context propagation

Tenant deletion, offboarding & data export isolation

Administrative impersonation auditing

BLOCKS LAUNCH Cross-tenant data exposure = critical, no exceptions

DOMAIN 02

Billing, Payments & Metering

Tests 16–30

Objective: protect revenue workflows — proration, dunning, tax, and checkout must be correct to the cent.

Webhook signature verification & idempotency

Mid-cycle upgrade / downgrade proration

Payment retry & dunning workflows

Usage-based metering calculation accuracy

Multi-currency, tax (VAT/GST) & localized invoicing

Double-submission prevention on checkout

BLOCKS LAUNCH Billing miscalculation = critical, no exceptions

DOMAIN 03

Authentication, Authorization & RBAC

Tests 31–45

Objective: protect identities and permissions — every session, token, and role boundary must hold.

Enterprise SAML/OIDC SSO & JIT provisioning

Privilege escalation prevention (horizontal & vertical)

JWT lifetime, claims & signature validation

Brute-force protection, rate limiting & lockout policy

Secure session cookies, CSRF & concurrent sessions

Password reset & invite token one-time usage

BLOCKS LAUNCH Authentication bypass = critical, no exceptions

DOMAIN 04

Performance, API Latency & Scalability

Tests 46–60

Objective: maintain responsiveness under real load, not just in the demo environment.

Baseline p95 & p99 tail latency under heavy traffic

Autoscaling trigger response & connection-pool exhaustion

Serverless cold-start latency

Cache hit ratios & slow-query performance budgets

Queue throughput, large-payload & CDN caching

Long-running soak test stability

FIX BEFORE LAUNCH High-severity — degrades experience at scale

The other four

Where trust and compliance are won or lost

Tests 61–108 round out the checklist: accessible by law, recoverable under failure, defensible under audit, and consistent across every device a customer might open you on.

DOMAIN 05 · 61–75

Accessibility Compliance (WCAG 2.2)

Keyboard navigation, screen-reader labeling, color contrast, focus order and form semantics — validated to WCAG 2.2 Level AA.

Objective: deliver accessible experiences

DOMAIN 06 · 76–88

Disaster Recovery & High Availability

Failover drills, backup restoration, RTO/RPO targets and multi-region resilience under real outage conditions.

Objective: maintain service continuity

DOMAIN 07 · 89–100

Privacy, Compliance & Security

Data protection, regulatory compliance and infrastructure hardening against the exploits your pen-test would look for.

Objective: protect data and infrastructure

DOMAIN 08 · 101–108

Cross-Browser, Responsive & Mobile QA

Consistent rendering and behavior across browsers, breakpoints and mobile viewports customers actually use.

Objective: maintain consistent experiences

Reading the results

Every failure gets a severity, not a shrug

Critical → blocks launch

High-severity → fix before launch

Moderate → assess before launch

After launch

QA doesn't end at the checklist

Passing 108 tests once is the floor, not the finish line. These five habits keep quality compounding after ship day.

Shift left

Catch defects in design and code review — every stage a bug survives multiplies its eventual fix cost.

Automate the repeatable

Regression suites, security scans and CI/CD quality gates replace manual re-checks for known risks.

Feed incidents back in

Every production incident should generate a new automated test or monitoring rule — never just a hotfix.

Set SLOs, not universal thresholds

Performance targets should reflect what your platform actually promises customers, not a generic industry number.

Design tenant-first

Isolation has to extend across databases, storage, caching, queues and third-party services — not stop at the application layer.