Walk through the customer's first session
Create a fresh account in the environment you plan to release. Follow verification or provider callbacks, reload the application, update a profile, and sign out. Repeat the journey on a narrow screen using a keyboard. Your normal development session can hide missing setup steps and stale state.
Check the messages that explain what to do next. An empty screen should offer a useful action. A failed request should explain how to retry without implying that work succeeded. Use the actual product's language in those messages, and make sure account and support links reach real destinations.
Repeat the journey once per sign-in method. OAuth callbacks for Google and GitHub each carry their own redirect and failure modes (the OAuth setup guide covers configuring them), and a provider's test consent screen behaves differently from a production one.
- Fresh account creation and session restoration work.
- Sign-out revokes access and clears the previous user's presentation.
- Empty, loading, and error states remain understandable on mobile.
- Every OAuth provider completes its callback on the real domain.
- Verification and reset emails arrive, read clearly, and link to the right environment.
- The first-run experience tells a new user what to do next.
Prove paid access at the server
Checkout is the easy half. Walk the whole lifecycle in the provider's sandbox: purchase, webhook received and verified, entitlement persisted, paid feature unlocked — then renewal, cancellation, and refund. Every transition should change server-owned state, not just a client flag. The billing guide shows where supastack keeps that state.
Then test the events you hope not to see: a webhook delivered twice, a failed payment, a subscription lapsing in the middle of a task. An entitlement answers “is this allowed right now” at request time; a dashboard badge does not.
- A sandbox purchase completes and unlocks the paid feature.
- Duplicate webhook deliveries are safe — processing is idempotent.
- Cancellation and refund revoke access at the server boundary.
- Per-seat or usage limits, if offered, reject beyond their terms.
Verify the boundaries with real dependencies
Use two independent accounts to verify ownership. Try retrieving and modifying one account's record from the other account, including task status and recovery URLs. Check paid access at the server action boundary, not only by hiding a button in the interface.
Workspace-scoped records are the spine of a multi-tenant product — the workspace boundaries post explains the model. Whatever your stack, the launch question is the same: does every read and write derive ownership from the server's authenticated context, with no record ID or client-sent workspace accepted as proof?
- Cross-workspace reads and writes are rejected.
- Recovery and task URLs do not grant access on their own.
- List and detail views enforce the same scoping.
- API keys and webhooks, if offered, carry workspace scope too.
Exercise the failure paths on purpose
Background work fails in two distinct ways, and each needs its own test. A failed dispatch leaves the client unsure whether anything was queued — a task-scoped idempotency key and a saved submission let recovery reuse the original request instead of duplicating it. A failed completion means the work ran but the result never arrived — retries and status polling should close that gap without a second generation.
Apply the same thinking to providers: an AI provider timeout, a bounced email, a billing API error. Each should end in a specific, explainable state rather than a silent half-result. The task recovery guide documents how the kit's production path handles this.
- A retry after a submission timeout does not duplicate work or cost.
- A failed completion is visible and recoverable, not a silent loss.
- Provider errors reach the user as honest states, not generic crashes.
Prepare for the first failure
Make sure someone can find an error, connect it to the relevant task, and help the user recover without exposing provider secrets. Confirm which logs and audit records exist, how long you retain them, and how an operator gets access to them.
Decide what “something is wrong” looks like before launch: failed job deliveries, webhook verification errors, a sudden climb in provider spend. An alert nobody receives is not monitoring — the observability setup covers wiring those signals.
Treat backups as an operational exercise: a configured backup is not the same as a restored one. Run the restore once, on data that resembles production, before the day you need it.
- An error can be traced to the request, user, and task that caused it.
- Logs and audit records have an owner, a retention policy, and access rules.
- A backup has been restored, not just configured.
- Failed jobs and webhook errors raise an alert a person receives.
Check the surfaces around the product
Legal and communication surfaces are part of launch, not polish: privacy and terms that describe what the product actually does, a support address that reaches a person, and a verified sender domain so transactional mail arrives from an address you own.
Read every automated email as a customer would. Verification, reset, receipt, and completion messages should carry the product's name, links to the right environment, and a reply path that is not a dead noreply address.
- Privacy and terms pages describe the product you actually run.
- Transactional mail sends from a verified domain you own.
- Support and billing questions have a reachable destination.
Make the go or no-go decision explicit
Assemble the release record: the build revision, the target environment, what was tested and how, and what remains unverified. A checklist with honest gaps beats a confident summary — the gaps are where the first incident usually lives.
Decide the rollback path before you need it: how to revert the deployment, what happens to data written in between, and who makes the call. Then launch the smallest version of the offer you can fully support, and widen it deliberately.
Common launch questions
Launch checklists fail in predictable places. These are the questions that catch most of them.
- What do most SaaS launches forget? — The ends of flows: sign-out that actually revokes, cancellation that actually removes access, and a restore drill for the backup that exists on paper.
- How many test accounts do I need? — At least two, in the target environment. Data isolation and invitation flows cannot be verified with one.
- Sandbox testing or production testing? — Both. Sandbox proves the lifecycle logic; a small real transaction proves keys, domains, and webhooks are wired to the right place.
- When is it safe to launch? — When every item protecting customer data or money is verified, and the unverified items are written down with owners — not when the feature list looks complete.
- What changes after launch? — Keep the release record, watch the failure alerts you configured, and re-run the checklist after any significant change to auth, billing, or scoping.