Launch a SaaS in production.

App, API, authentication and payment return URLs are all HTTPS on your domain; the return URLs declared with providers point to production.

Verify: Review the redirect URLs configured with the authentication and payment providers.

Evidence: List of configured return URLs.

MDN — Strict-Transport-Security ↗ · reviewed 2026-10-23

Each environment has its own keys and its own database; a preview never touches production data or emails real customers.

Verify: Compare production and preview environment variables: no production key in preview.

Evidence: Table of variables per environment (names only, never values).

Database service keys, secret payment keys, AI keys and webhook secrets stay server-side — never in a browser-exposed variable or in Git history. An exposed key is revoked.

Verify: Search for key prefixes in the repository, its history and the JavaScript served to the browser.

Evidence: Search result.

OWASP — Secrets Management Cheat Sheet ↗ · reviewed 2026-10-23

The live version runs on the real domain with production configuration, migrations are applied, the main journey was repeated after deploying, and the rollback procedure (code and data) is known and has been tried.

Verify: After the last deployment: main journey on the production domain; rollback tried on a preview.

Evidence: Deployment ID, test date and rollback procedure.

Common failure: An environment variable missing in production: sign-up fails for every new customer.

Sign-up, sign-in, sign-out, forgotten password or expired magic link, session expiry, private page opened while signed out: each case has a planned, tested behaviour.

Verify: With a new account in production, run each case, including an expired link and a private page in a private window.

Evidence: Dated list of the cases tested and their result.

Common failure: A private page still reachable after sign-out through the Back button or a direct URL.

OWASP — Authentication Cheat Sheet ↗ · reviewed 2026-10-23

Every read and write checks, on the server or in the database (RLS), that the resource belongs to the signed-in person. Account A can neither see nor change account B’s data, through the UI, the API or by changing an ID in the URL.

Verify: With two accounts, copy the ID of one of B’s resources and try to read and change it from A (UI and direct request).

Evidence: Requests attempted and refused responses.

Common failure: RLS disabled “to make it work”: every row readable by everyone.

OWASP — Authorization Cheat Sheet ↗ · reviewed 2026-10-23

A member can only do what their role allows; a person removed from a team loses access immediately, including to links they had.

Verify: Test each sensitive action with each role, then remove a member and try again.

Evidence: Role × action matrix with results.

OWASP — Authorization Cheat Sheet ↗ · reviewed 2026-10-23

A person can delete their account or request it, knows what is deleted and what is kept (invoices, legal obligations) and why.

Verify: Delete a test account and check in the database what remains.

Evidence: Deletion path and list of retained data.

Sign-in, sign-up, reset, email sending and costly actions are rate-limited, to slow credential stuffing, spam and surprise bills.

Verify: Repeat a reset request twenty times: the server eventually refuses.

Evidence: Configured limits and test result.

OWASP — Authentication Cheat Sheet ↗ · reviewed 2026-10-23

Every database change is a versioned migration, applied the same way to every environment — never a manual change in the dashboard. Destructive migrations are tested on a copy.

Verify: Compare the production schema with the one produced by the repository’s migrations.

Evidence: Last migration applied in production.

Backups are enabled, their retention is known, and a restore has been done at least once: you know how long it takes and which data would be lost.

Verify: Restore a recent backup into a test project and check a few records.

Evidence: Date and duration of the last restore.

Common failure: A backup never tested, unusable the day it is needed.

No high-privilege key on the client; RLS enabled on exposed tables; only the tools and people who need it access production, with strong authentication.

Verify: List exposed tables and their RLS policy; list the people with production access.

Evidence: Those two lists.

Supabase — Row Level Security ↗ · reviewed 2026-10-23

Type and size checked on the server, private storage, signed expiring links, and no uploaded file served as executable content from your domain.

Verify: Upload a too-large file and an HTML file renamed as an image: both are refused.

Evidence: Result of both tests.

OWASP — Top 10 ↗ · reviewed 2026-10-23

A real production payment succeeds, and access is granted by the server after a webhook event whose signature is verified — never by the success page, which anyone can open without paying.

Verify: Real payment with your card then refund; open the success page without paying: no access is granted; send an unsigned webhook: it is refused.

Evidence: Payment reference, verified webhook log, response to the unsigned webhook.

Common failure: Test webhook secret in production: every real payment fails to grant access.

Stripe Docs — Receive Stripe events in your webhook endpoint ↗ · reviewed 2026-10-23

Payment providers may deliver an event more than once and out of order. Store processed event IDs so a redelivery does not grant access twice or send two emails.

Verify: Resend the same event from the provider dashboard: nothing changes the second time.

Evidence: Log of both deliveries.

Stripe Docs — Idempotent requests ↗ · reviewed 2026-10-23

The browser cannot choose the amount or the plan paid; the server decides from known IDs. Test keys are never used in production, and vice versa.

Verify: Change the price or plan in the request sent by the browser: the server ignores it.

Evidence: Test result and key mode in production.

Stripe Docs — API keys ↗ · reviewed 2026-10-23

What happens when a renewal fails is decided: retries, an email to the customer, a grace period, then access suspension.

Verify: Simulate a failed renewal and check emails and access state at each step.

Evidence: Written policy and simulation result.

Stripe Docs — Revenue recovery ↗ · reviewed 2026-10-23

Updating a card, viewing invoices and cancelling are possible without contacting support.

Verify: With a customer account, change the card, download an invoice, cancel.

Evidence: Screenshots of each action.

Stripe Docs — Customer management ↗ · reviewed 2026-10-23

Plan change, end-of-period cancellation, refund and access removal produce the expected state in your database and at the provider.

Verify: Run each transition with a test customer and compare your database with the provider dashboard.

Evidence: Table of transitions and resulting state.

Stripe Docs — How subscriptions work ↗ · reviewed 2026-10-23

Card required or not, duration, reminder before the end, and what happens when it ends are decided and shown clearly.

Verify: Create a short trial in test mode and follow it to the end.

Evidence: Follow-through result and the text shown to the customer.

Stripe Docs — Trials ↗ · reviewed 2026-10-23

Terms and refund policy published; VAT handling checked for your sales countries. Check what applies to you; this is not legal or tax advice.

Verify: Links to the terms appear before payment.

Evidence: Terms and refund policy URLs.

Every server action and API route validates its inputs (type, size, format) and never builds SQL queries or commands from user-provided text.

Verify: Send empty, too long and unexpected values to each form: the server refuses cleanly.

Evidence: List of actions tested.

OWASP — Top 10 ↗ · reviewed 2026-10-23

The lockfile is committed and the dependency audit reports no unaddressed critical vulnerability.

Verify: Run your package manager’s audit and fix or justify every critical alert.

Evidence: Dated audit result.

OWASP — Top 10 ↗ · reviewed 2026-10-23

Admin requires strong authentication, is not protected only by a secret URL, and sensitive actions are logged.

Verify: Open admin routes signed out and with a customer account: refused.

Evidence: Test result.

OWASP — Authorization Cheat Sheet ↗ · reviewed 2026-10-23

Passwords, tokens, magic links, card numbers and private content do not appear in logs or error-tracking tools.

Verify: Search recent production logs for “token”, “password” and email addresses.

Evidence: Search result.

OWASP — Top 10 ↗ · reviewed 2026-10-23

Model calls go from the server; each user has a usage limit, and a spending cap or alert is configured with the provider.

Verify: Search for the key in the code sent to the browser; exceed the limit with a test account.

Evidence: Configured limits and provider cap.

Common failure: Key exposed in the browser, a bill of thousands overnight.

OWASP — Top 10 for LLM Applications ↗ · reviewed 2026-10-23

Uploaded documents, web pages, emails: what the model reads may contain malicious instructions. Its outputs trigger no privileged action without a server-side check, and its tools have minimal permissions.

Verify: Put “ignore previous instructions and…” in a test document: the system does not act on it.

Evidence: Test result and list of tools the model can use.

OWASP — LLM Prompt Injection Prevention Cheat Sheet ↗ · reviewed 2026-10-23

Users know when an answer comes from a model, which data goes to which provider, and what happens if the model is unavailable.

Verify: Disable the AI key in staging: the app shows an understandable state.

Evidence: Disclosure text and screenshot of the degraded state.

Hosting, database, email, payments, analytics, AI: each processor is listed with its purpose. Check what applies to you (Swiss FADP, GDPR if you target the EU), including transfers outside Switzerland or the EU. This is not legal advice.

Verify: Compare the processor list with the services actually connected.

Evidence: Policy URL and processor list.

Fedlex — Swiss Federal Act on Data Protection (FADP) ↗ · reviewed 2026-10-23

Events carry no email, name or free text; consent is collected where required. Check what applies to you.

Verify: Inspect the properties of events sent during a full journey.

Evidence: List of events and their properties.

EUR-Lex — General Data Protection Regulation (GDPR) ↗ · reviewed 2026-10-23

Health, finance, children’s data: collect only what is needed, limit who accesses it, log access and set a retention period. Such data often carries stricter obligations: check what applies to you.

Verify: List each sensitive field, why it exists, who accesses it and when it is deleted.

Evidence: That register.

Fedlex — Swiss Federal Act on Data Protection (FADP) ↗ · reviewed 2026-10-23

Server and client errors reach a tracking tool, and an alert reaches a responsible person — not only logs nobody reads.

Verify: Trigger a controlled error in production: the alert arrives.

Evidence: Screenshot of the alert received.

Sign-in links, receipts and notifications are sent from an authenticated domain (SPF, DKIM, DMARC) and land in the Gmail and Outlook inbox. A sign-in link in spam locks people out of the product.

Verify: Trigger each email to Gmail and Outlook; check the inbox and the authentication headers.

Evidence: Screenshots of delivery and headers.

Google Workspace Admin Help — Email sender guidelines ↗ · reviewed 2026-10-23

Monitoring checks the key endpoints (home, sign-in, API) and you know where to inform customers during an outage.

Verify: Take a test endpoint down: the alert arrives.

Evidence: Chosen tool and status channel.

Who is alerted, how to return to the previous version, how to restore data, how to inform customers: written before it is needed.

Verify: Someone else can follow the procedure without you.

Evidence: Link to the procedure.

Sign-up → first value → payment (if any), on Safari, Chrome and Firefox, mobile and desktop, on the production domain.

Verify: Repeat the journey after the last deployment with a new account.

Evidence: Dated list of browsers and devices tested.

Visible focus, labelled fields, error messages tied to fields, sufficient contrast on the main journey.

Verify: Do the main journey using only the keyboard.

Evidence: Test result.

W3C — Web Content Accessibility Guidelines (WCAG) 2.2 ↗ · reviewed 2026-10-23

Explicit empty states, an obvious first action, no blocking setup: the person understands what they can do in the first session.

Verify: Watch an outsider create an account, without helping.

Evidence: Observation notes.

Each plan’s limits (and anti-abuse limits) are enforced by the server, and the person knows what happens when they reach them.

Verify: Reach the limit with a test account: the message is clear and the server blocks.

Evidence: Limits per plan and test result.

A support link visible in the app, a monitored inbox and a response time you can keep.

Verify: Write to support from a customer account: someone answers within the stated time.

Evidence: Stated response time and first test.

An activation event (first value obtained) and a retention measure are defined and instrumented, without personal data, to know whether the product is actually useful.

Verify: Complete activation with a test account: the event appears.

Evidence: Definition of both measures.

Marketing pages are indexable with a correct canonical URL and appear in the sitemap; the dashboard, account pages, private results and preview deployments are not indexable (authentication or noindex). robots.txt blocks nothing important.

Verify: Read /robots.txt and /sitemap.xml; inspect a public page and a private page (robots tag, canonical); open a preview URL.

Evidence: Inspection results.

Common failure: Account pages indexed with customer data visible in results.

Google Search Central — Block indexing with noindex ↗ · reviewed 2026-10-23

Each public page has a unique title and description and a share image.

Verify: Record titles and descriptions of public pages: no duplicates.

Evidence: Table of titles and descriptions.

Google Search Central — Title links ↗ · reviewed 2026-10-23