Everything you need to check before you ship — organized by category, prioritized by risk

Most SaaS launches go wrong in one of two ways.

Either the team ships too fast and catches critical bugs from real users instead of QA. Or they over-test, delay the launch, and miss the market window they were building toward.

The answer isn’t more testing or less testing. It’s the right testing — focused on what actually breaks in production, in the order that matters.

This checklist covers six categories that between them account for the vast majority of launch failures we see at TestMatick. Functional issues that break core user flows. Security vulnerabilities that expose user data. Performance problems that collapse under real traffic. Compatibility gaps that make the product unusable on half your users’ devices. Accessibility failures that block entire user segments. And the smoke test that tells you whether your production environment actually works the way staging told you it would.

Work through it in order. The categories are sequenced by the cost of getting them wrong — functional bugs are embarrassing, security failures are catastrophic. Check off what passes. Fix what doesn’t. By the time you reach the bottom, you’ll have a clear picture of whether your product is ready to ship — and what’s standing in the way if it isn’t.

1. Functional Testing

Start here. Functional testing covers whether your product does what it’s supposed to do. No shortcuts.

This is the category most teams think they have covered — and the one where the most launch-day surprises happen. The reason is usually the same: developers test the happy path. QA tests everything else. The edge cases, the error states, the flows that users take that nobody designed for. Cover the categories below systematically, not just the flows your team uses most often.

Core user flows

• User registration and login work end-to-end
• Password reset flow completes successfully
• Email verification sends and links work
• OAuth / SSO login works if applicable (Google, GitHub, etc.)
• User can complete the primary action your product exists to enable
• User can edit and update their profile or settings
• User can delete their account and all associated data

Subscription and billing

• Free trial signup works without payment details if applicable
• Paid plan upgrade flow completes without errors
• Payment failure is handled gracefully with clear error messaging
• Subscription cancellation works and triggers correct account state
• Invoice generation and delivery works correctly
• Proration is calculated correctly for mid-cycle plan changes
• Webhook events from payment provider are handled correctly

Data integrity

• Data saves correctly and persists after page refresh
• Concurrent edits by multiple users don’t cause data corruption
• Data export works and produces accurate, complete files
• Data import handles malformed files without crashing
• Search returns accurate results across all relevant fields
• Filters and sorting work correctly and consistently
• Pagination works at scale — test with large data sets

Notifications and emails

• Transactional emails send correctly (welcome, reset, invoice, etc.)
• Email templates render correctly across major email clients
• In-app notifications appear and dismiss correctly
• Notification preferences save and apply correctly
• Unsubscribe links work and update preferences immediately

2. Security Testing

Security failures are the most expensive bugs you can ship. These are the non-negotiables.

Unlike functional bugs — which are visible and get reported — security vulnerabilities can sit undetected for months while user data is exposed. By the time you find out, the damage is done. The items below cover the most common attack vectors in SaaS applications. They’re not exhaustive, but they cover the failures that show up most often in post-breach analyses. If your product handles sensitive user data, consider a dedicated penetration test in addition to this checklist.

Authentication and authorization

• Unauthenticated users cannot access protected routes
• Users cannot access other users’ data by manipulating IDs in URLs or API calls
• Session tokens expire correctly and cannot be reused after logout
• Failed login attempts are rate-limited
• Password requirements are enforced on both client and server
• Multi-factor authentication works correctly if implemented

Data protection

• Sensitive data (passwords, tokens, PII) is never logged
• API responses don’t leak data beyond what the requesting user should see
• File uploads are validated for type and size — no arbitrary file execution
• SQL injection is not possible in any user-input field
• XSS vulnerabilities are not present in user-generated content rendering
• CSRF protection is in place for state-changing requests

Infrastructure

• HTTPS is enforced everywhere — no mixed content warnings
• Security headers are configured correctly (CSP, HSTS, X-Frame-Options)
• Error messages don’t expose stack traces or internal system details
• Dependency vulnerabilities are scanned and addressed
• Environment variables and secrets are not exposed in client-side code

3. Performance Testing

Your product needs to work under load. Not just when it’s you and your team testing it.

Performance problems have a specific pattern: everything works fine in development and staging, then launch day brings real traffic and something collapses. Database queries that were fast with 100 records become slow with 100,000. API endpoints that handled 10 concurrent users fall over at 500. The items below are designed to surface these problems before your users do. Pay particular attention to load testing — most teams skip it because it’s harder to set up, and most launch-day incidents trace back to it.

Response time benchmarks

• Page load time under 3 seconds on standard connection
• API response time under 500ms for standard operations
• Database queries are optimized — no N+1 query problems
• Search and filtering operations return results within 2 seconds
• File uploads complete within acceptable time for maximum allowed file size

Load testing

• Application handles expected launch-day traffic without degradation
• Database connection pooling is configured for concurrent users
• Background jobs don’t block main application threads under load
• CDN is configured for static assets
• Caching is in place for expensive operations
• Auto-scaling is configured if using cloud infrastructure

4. Browser and Device Compatibility

Your users are not all using the same browser on the same device. Test where they actually are.

The most common compatibility mistake is testing only on the devices the development team uses. If your team is on MacBooks running Chrome, you’ll catch Chrome bugs and miss everything else. Safari on iOS is particularly important for US SaaS products — it’s the default browser for a significant portion of your user base, and it has specific rendering and JavaScript behavior differences that Chrome doesn’t. Test on real devices where possible, not just browser developer tools in responsive mode.

Browser coverage

• Chrome (latest two versions)
• Safari (latest two versions — critical for iOS users)
• Firefox (latest version)
• Edge (latest version)
• Chrome on Android (latest version)
• Safari on iOS (latest two versions)

Responsive design

• Layout is functional and readable at 320px width (smallest common mobile)
• Layout is functional at 768px (tablet)
• Layout is functional at 1024px, 1280px, and 1440px (desktop)
• Touch targets are large enough on mobile (minimum 44px)
• Forms are usable on mobile keyboard — no fields obscured by keyboard
• Horizontal scrolling is not present on any screen size

5. Accessibility (WCAG 2.1)

Accessibility is not optional. It’s a legal requirement in many jurisdictions and a quality signal for enterprise buyers.

In the US, the Americans with Disabilities Act has been applied to web applications in an increasing number of court cases. Enterprise procurement processes increasingly include accessibility audits as part of vendor evaluation. Beyond the legal and commercial considerations, roughly 15% of the global population has some form of disability that affects how they interact with software. The items below cover the WCAG 2.1 AA standard — the most commonly required level for US business applications. Automated tools like Axe or Lighthouse catch about 30% of accessibility issues. The rest require manual testing.

Core accessibility checks

• All images have meaningful alt text
• Color contrast meets WCAG AA minimum (4.5:1 for normal text)
• All interactive elements are keyboard navigable
• Focus order is logical and visible
• Form fields have associated labels
• Error messages are associated with the field that caused them
• Page titles are unique and descriptive
• Headings are used in logical hierarchy (H1 > H2 > H3)
• No content flashes more than 3 times per second (seizure risk)
• Screen reader testing passes for primary user flows

6. Pre-Launch Smoke Test

Run this on your production environment — not staging — the day before launch. If anything fails here, do not ship.

Staging environments lie. They’re configured differently, seeded with different data, connected to different third-party services. The only environment that tells you the truth about your production readiness is production itself. Run this smoke test after your final deployment, with real credentials, on real infrastructure. Treat any failure as a launch blocker — because it is. A bug found here costs hours. The same bug found by your first 100 users costs customers.

Production smoke test

• New user can sign up and complete onboarding end-to-end
• Existing user can log in and access their data
• Payment processing works with a real test transaction
• Primary product feature works as expected
• Email delivery works from production mail infrastructure
• Error tracking is active and receiving events
• Analytics are firing correctly
• Support chat or contact form works
• All external integrations are connected and responding
• SSL certificate is valid and not expiring within 30 days

One more thing

A checklist is only as good as the process behind it. Running through these items manually before every launch works for a while. It stops working when your release cadence increases, when your team grows, and when the product gets complex enough that manual coverage becomes impossible.

The teams that ship confidently at scale automate the repeatable parts of this checklist — regression testing, performance benchmarks, security scans — and reserve manual testing for the parts that require human judgment. New features. Edge cases. Exploratory testing that follows the unpredictable paths real users take.

The transition from manual-only to hybrid testing usually happens at the same point in a company’s growth: when the team starts shipping faster than they can manually test. If you’re already there, you already know it. Releases feel riskier than they used to. QA becomes a bottleneck. Bugs that manual testing should have caught make it to production.

That’s not a people problem. It’s a process problem. And it has a straightforward solution.

The right QA partner helps you build a testing process that scales with your product — one that gives you confidence at launch day one and keeps giving it as the product grows. That’s what we do at TestMatick, and it’s what a full QA audit is designed to assess.

If you’re shipping soon and you want a second set of eyes on your readiness — or if you’re building toward a bigger launch and want to get the testing infrastructure right before you need it — the conversation starts with a free pilot project. No contract. No commitment. Just a clear picture of where you stand.

Want a full QA audit before your launch?

TestMatick has been helping SaaS companies ship with confidence since 2009. We’ll run through this checklist — and everything that isn’t on it — before your next launch. Free pilot project available, no contract required.

-> Get Your Full QA Audit — testmatick.com