A Pre-Launch Checklist for SaaS on AWS

Most launch-day problems aren't in the product's features. They're in the boring infrastructure around it: password reset emails landing in spam, a database with no tested backup, a payment webhook anyone could call, an AWS bill nobody was watching.

This is the checklist I run before a SaaS product on AWS goes in front of real users. None of it is glamorous, and all of it is cheaper to do before launch than after.

Domain, DNS and email

• DNS is managed in one place (Route 53 or your registrar), and you know who has access.
• HTTPS everywhere, with certificates that renew automatically (AWS Certificate Manager handles this for CloudFront and load balancers).
• DNSSEC is considered for the domain, especially if customers will trust it with payments or personal data.
• Email authentication is set up: SPF, DKIM and DMARC. Without them, sign-up confirmations and password resets go to spam, and users think your product is broken.
• Transactional email goes through a proper service like Amazon SES, out of the sandbox, with bounce and complaint handling.
• Send yourself every email the product sends (sign-up, reset, invoice, notification) and check it arrives in the inbox, not spam.

Secrets and access

• No secrets in the code or the frontend bundle. API keys live in AWS Secrets Manager or Parameter Store and are read at runtime.
• IAM follows least privilege. Each service has its own role with only the permissions it needs. No application runs with admin credentials.
• The root account is locked away with MFA, and humans use individual IAM users or SSO.
• Third-party keys (Stripe, OpenAI, others) are production keys, scoped and rotated, not the test keys someone used during development.

Data and backups

• Automated database backups are on with a retention period that matches what you'd need to recover.
• A restore has actually been tested. A backup you've never restored is a hope, not a backup.
• S3 buckets are private by default, with public access blocked unless a bucket is deliberately public.
• Personal data is identified, so you know where it lives and who can reach it.

Deployments

• Infrastructure is defined as code (CloudFormation, Terraform or AWS SAM), so production can be rebuilt and every change can be reviewed.
• Deploys go through CI/CD, not someone's laptop.
• Staging and production are separate, with separate credentials and data.
• There's a rollback path. You know how to return to the previous version in minutes when a release goes wrong.
• Database migrations are part of the pipeline and are safe to run against live data.

Monitoring and alerts

• Logs are centralized (CloudWatch or similar) and searchable, with sensitive values kept out of them.
• Alarms exist for what matters: error rates, API latency, failed background jobs, database storage and CPU.
• Alerts reach a human, by email or chat, not a dashboard nobody opens.
• Uptime is checked from outside, so you hear about downtime before your customers tell you.

Payments and webhooks

• Webhook signatures are verified. A Stripe webhook endpoint that doesn't check the signature lets anyone mark an invoice as paid.
• Webhook handlers are idempotent, because providers retry and the same event can arrive twice.
• Failed payments and cancelled subscriptions are handled in the product, not just in the Stripe dashboard.

Security basics

• Rate limiting on authentication and public APIs, to slow down brute-force attempts and abuse.
• Input validation on every endpoint, on the server, not only in the frontend.
• CORS is restricted to your own domains.
• Dependencies are up to date, with known vulnerabilities patched.
• AI endpoints have usage limits, because a public route that calls a paid model can be abused to run up your bill.

Cost

• AWS Budgets and billing alarms are on, set below the number that would hurt.
• Resources are sized for launch, not for an imagined future. It's easy to scale up later.
• Cost allocation tags separate production, staging and experiments, so you can see what's actually costing money.

Launch day

• Someone knows they're on call, and knows how to roll back.
• The team has run through sign-up, payment and the core workflow in production with a real account.
• Support has a way to reach the engineer when something odd happens.

Doing this without a DevOps hire

Small teams rarely have a dedicated DevOps engineer, so this checklist often gets skipped. The good news is that most of it is a one-time setup that keeps paying off for the life of the product.

If you're preparing a launch and want a second pair of eyes, or want this set up properly from the start, here's how I help with AWS and DevOps for small teams. And if you're still building the product itself, start with how to build a SaaS MVP without overengineering it.