SaaS launch checklist: what to check before the first paying customer signs up

1 Billing and money

• Switch to live API keys, make sure no key sits in the code, and rotate any key that was shared during development.

  Stripe's go-live checklist calls for exactly this; a test key left in one service is the classic launch-day failure.

  Official source

• Register the production webhook endpoints and verify every event's signature before acting on it.

  Stripe signs events in the Stripe-Signature header; Razorpay sends an HMAC SHA256 signature of the raw body in X-Razorpay-Signature. An unverified endpoint accepts forged payment events.

  Official source

• Make webhook handling safe to repeat: record each event ID before processing it and ignore a second copy.

  Stripe's checklist says endpoints must cope with delayed and duplicate notifications that arrive in any order.

  Official source

• If you use Razorpay, put About us, Contact us, Pricing, Terms and conditions, Privacy policy and Refunds policy pages live before activation.

  Razorpay will not issue live-mode API keys without your website or app details and links to these pages.

  Official source

• If you bill Indian customers with GST, number tax invoices in a consecutive series that is unique for each financial year, and freeze each invoice when it is issued.

  The GST invoice rules require a consecutive serial number, in one or more series, unique for a financial year.

  Official source

• Run renewals, failed payments, refunds and plan changes end to end in test mode, and check each one lands correctly in your own records.

  Billing bugs surface weeks after launch, at the first renewal, when they are hardest to unwind.

2 Tenants, roles and access

• For every list and detail route, sign in as customer B and request customer A's records by ID; every request must fail.

  Broken access control is A01, the first entry, in the OWASP Top 10:2025.

  Official source

• Give each staff role only the permissions it needs, require two-factor sign-in for staff, and make admin routes refuse access when a permission is missing.

  An admin console is the most valuable account in the product; a route that fails open is a breach waiting for a curious user.

• Rate-limit sign-in, one-time codes and password resets.

  Authentication failures are A07 in the OWASP Top 10:2025, and unlimited attempts invite credential stuffing.

  Official source

3 Reliability

• Exercise every API route over HTTP before launch and record which ones have been run, rather than ticking a to-do list.

  A hand-kept list drifts from the code; a route nobody has called is a route nobody knows works.

• Send errors to an error tracker in the company's own account, with source maps uploaded at build time.

  Without source maps a production stack trace is unreadable; without your own account, the history leaves with the vendor.

• Set up uptime monitoring that alerts a named person, and write down the hours in which someone will respond.

  Customers will ask what happens when it breaks at night. The honest answer is in the contract, not the marketing page.

• Restore last night's backup into a scratch database and open the app against it.

  A backup that has never been restored is a hope, not a backup.

• Store and compare dates in UTC, and convert to the user's time zone only when displaying them.

  Mixed time zones put bookings, renewals and reports on the wrong day without throwing an error.

4 Email and search

• Authenticate your sending domain with SPF or DKIM; if you send 5,000 or more messages a day to Gmail, set up SPF, DKIM and DMARC and one-click unsubscribe for marketing mail.

  Gmail's sender guidelines have applied these requirements since 1 February 2024, along with valid reverse DNS, TLS and a reported spam rate below 0.3%.

  Official source

• Remove the staging noindex tag or header and any robots.txt block on the production site.

  Google drops a page carrying noindex from its results, and a robots.txt block stops Google seeing the page at all.

  Official source

• Check that every public page serves its own title, description and canonical URL in the HTML, then submit the sitemap in Search Console.

  Google treats a sitemap as a hint for discovery, so the pages themselves must carry their metadata.

  Official source

5 Customers and support

• Publish a support address that a named person reads every working day, and a contact for privacy questions.

  India's DPDP Rules (Rule 9) will require a published contact for data questions eighteen months after their publication, 13 May 2027 by our count; customers expect one from the first day.

  Official source

• Write the cancellation and refund rules in plain words and make the product follow them exactly.

  A refund policy the code does not implement is the fastest way to a chargeback.

What did these checks catch in our own builds?

Questions about this checklist