Django SaaS Launch Checklist

Problem statement

Launching a Django SaaS means real customers paying real money and trusting you with their data from day one. Beyond a working app, a launch needs tenant data isolation that cannot leak, billing that stays in sync with access, emails that arrive, backups that restore, monitoring that wakes someone up, and the legal and support basics customers expect. Missing any of these turns launch week into firefighting. This checklist groups the essentials by area so nothing critical is left for "after launch".

1. Production settings pass check --deploy; HTTPS, HSTS, and secure cookies are on.
2. Tenant isolation is enforced in queries and tested (one customer can never see another's data).
3. Authentication: email verification, password reset, rate limiting, and 2FA at least for admins.
4. Billing: Stripe (or similar) webhooks verified, idempotent, and reconciled with access.
5. Email: authenticated domain (SPF, DKIM, DMARC), transactional provider, bounce handling.
6. Backups tested, monitoring and alerting live, legal pages published, support channel staffed.

Checklist

Platform and security

• DEBUG = False, ALLOWED_HOSTS, SECURE_* settings, python manage.py check --deploy clean.
• Secrets in a secret manager or environment, not in the repository; rotation documented.
• Dependencies pinned and scanned; images rebuilt regularly.
• Admin protected (2FA, ideally not public), staff accounts named per person.

Tenants and data

• Every tenant-scoped query filters by tenant (custom managers, middleware, or django-tenants schemas).
• Automated tests prove a user from tenant A cannot read or modify tenant B's objects via views and APIs.
• File uploads stored per tenant with access checks or signed URLs.
• Data export and account deletion paths exist for customers.

Authentication and accounts

• Email verification on signup; password reset tested end to end.
• Login rate limiting (django-axes, edge rules) and bot protection on signup.
• 2FA available for users and required for staff.
• Session security: secure cookies, sensible expiry, logout everywhere on password change.

Billing

• Payment provider webhooks verified by signature, stored by event ID, processed idempotently in the background.
• Subscription state drives access (trial end, failed payment, cancellation) and is reconciled daily against the provider.
• Test and live keys separated; tax and invoice settings configured.

Email

• Sending domain authenticated with SPF, DKIM, and DMARC; transactional provider configured.
• Bounces and complaints handled; marketing email separated from transactional.
• Templates tested on major clients; links use the production domain.

Operations

• Backups automated off-site, restore tested and timed; PITR if data loss tolerance is low.
• Error tracking (Sentry), uptime checks, heartbeats for scheduled jobs, and alerts routed to someone on call.
• Deploy pipeline with tests, migrations, smoke tests, and rollback.
• Capacity checked with a load test at expected launch traffic.

Legal and support

• Terms of service, privacy policy, cookie notice, and data processing agreement available.
• Status page or communication plan for incidents.
• Support email or helpdesk staffed during launch; incident runbook written.

Explanation

A SaaS product adds three risks to an ordinary web app: multi-customer data in one system, money flowing through it, and contractual expectations of availability and data protection. Tenant isolation must be enforced by design and tested, because a single missing filter leaks data across customers. Billing must be event-driven and idempotent, because payment providers deliver events asynchronously and sometimes twice. Operational basics (backups, monitoring, deploy safety) and trust basics (legal pages, support) complete what customers implicitly expect when they pay.

Edge cases / notes

• Single-tenant enterprise deals may require dedicated databases or deployments; design so that is possible.
• Data residency requirements can dictate hosting regions; decide before launch.
• SOC 2 or ISO 27001 expectations from larger customers start with many items on this list.
• Feature flags let you launch to a subset of customers first.

Next steps

• Run the cutover with the Django Go-Live Runbook.
• Billing details: Handle Stripe Webhooks in Production Django.

FAQ

What is most important before launching a Django SaaS?

Tenant data isolation, tested backups, secure settings, reliable billing webhooks, and monitoring with alerts.

How do I prove tenant isolation?

Automated tests that try to access another tenant's objects through every view and API, and query-level tenant filtering by default.

Do I need 2FA at launch?

At minimum for staff and admin accounts; offering it to customers builds trust.

When should backups be tested?

Before launch and regularly after, with a timed restore into a scratch environment.