A Pre-Launch Testing Checklist for Your First SaaS
Your application works in the browser you have used to build it. That browser also has a verified account, a selected workspace, saved data, and permissions you granted yourself weeks ago.
A first customer starts somewhere else. They arrive through a public link, have no account, and need to discover how to get a useful result.
Before launching, walk that route on the deployed release candidate. Use this checklist to define a bounded review, then add checks for the particular risks of your product. A scheduling app, for example, needs explicit time-zone checks; a file-sharing app needs explicit sharing boundaries.
Prepare the launch candidate
Record the version, URL, and time of the review. Use an environment configured like the intended deployment, with isolated test data and the integrations needed for the journey.
Prepare a fresh account, an existing account, and any supported roles. Have access to a test inbox you control if email verification is part of signup. Use the billing provider’s sandbox for payment scenarios.
List the external services the launch depends on. Mark any that are mocked or unavailable so the result accurately describes what you tested. A simulated email response can check application handling; it cannot prove that a customer receives the deployed email.
Check the public entry and account flow
Open the actual link you intend to share. Follow the primary signup call to action and complete the supported signup method.
| Check | Pass condition |
|---|---|
| Public entry | Shared URL loads and its primary action reaches the intended signup page |
| Signup | A valid submission creates one account and explains the next step |
| Invalid submission | Missing or invalid fields produce a useful message without losing unrelated input |
| Verification, if required | The test inbox receives the message and the link completes verification |
| Existing account | Attempting signup with an existing account offers a workable way to sign in |
| Recovery | The supported password or account recovery method returns the owner to their account |
| Sign-out | A fresh visit to a protected page requires authentication |
Check the path you advertise. If you offer multiple sign-in methods, make a coverage decision for each instead of treating one successful method as proof of all of them.
Follow onboarding until the user gets value
Choose one concrete outcome: create a project, publish a booking page, generate a usable report, or complete the equivalent first task in your product.
Use the fresh account. Read the empty state, follow its action, and complete the task without using an internal shortcut. Reload afterward and confirm the result is still available.
Check interruption as well. Leave during setup, sign in again, and verify that the user can resume or safely start over according to the intended behavior. An account that exists but cannot complete setup needs an explicit recovery route.
For a deeper walkthrough, see testing SaaS onboarding.
Verify the data users will trust
Create a uniquely named disposable record. Open it from the list, change a field, save, reload, and compare the saved value. If the product supports deletion, delete that record and confirm the documented result.
If workspaces or roles exist, repeat the relevant read and write checks with the intended account. Your owner account cannot establish whether a regular member sees the right data.
For uploads, exports, or generated files, inspect the output. A completed progress indicator does not prove that a file contains the expected content. Include a representative supported file and a rejected input to check the failure path.
Check billing against the advertised offer
If launch includes paid access, test a successful purchase, an abandoned checkout, and a provider-simulated failure in the sandbox. Compare the displayed plan and billing interval before checkout with the product access afterward.
Reload billing settings and try the paid action itself. A changed plan badge alone is incomplete evidence. Follow your product’s documented rules for upgrades, cancellation, and when access ends.
Stripe’s testing documentation explains its sandbox payment scenarios. Use the equivalent official tools for your provider. The subscription testing guide covers the application-side checks in more detail.
Review a phone and a second browser
Pick devices and browsers based on the audience you expect at launch. On a narrow screen, check navigation, form entry, validation messages, dialogs, and the final action of the primary journey. Open the same journey in another browser you intend to support.
Pay attention to keyboard use. Tab through the main form, verify visible focus, and confirm that inputs and errors can be understood through their labels. This is a useful usability check; it is not a complete accessibility audit.
Capture actual failures with the account state and viewport size. “Mobile looks odd” is harder to fix than “the submit button is outside the dialog at this width and cannot be reached by scrolling.”
Make an explicit launch decision
Put findings into a short release note:
- Verified: Journey, account type, environment, and version.
- Failed: Expected result, observed result, and reproduction steps.
- Blocked: Missing dependency or setup that prevented a check.
- Deferred: Untested scope and why you accepted it.
- Decision: Release, fix first, or remove the affected feature from launch.
A broken core journey, lost data, incorrect paid access, or an access-boundary failure deserves an explicit fix or scope decision before exposure. A minor visual issue may be acceptable if it does not prevent the task; record that judgment.
Save repeatable checks as you go. In HiTest, create the first test around one launch-critical journey and review its actual result. The next release can reuse that evidence structure instead of rebuilding a checklist from memory.