SaaS Production Checklist:14 Checks Before You Go Live
The SaaS production checklist: 14 technical checks — SSL, backups, security rules, secret keys, rollbacks — to run before real users touch your product.
Before your SaaS goes live, run one SaaS production checklist: security rules enabled and tested on every database table, secret keys out of your code, SSL active, backups verified, and a rollback you've actually rehearsed. Launch marketing gets all the attention — but the unglamorous go-live checks are what decide whether your first real users meet a working product or a data breach.
This is the technical half of launching. The marketing half — the announcement, the channels, the momentum — is the launch week playbook. Today is about making sure the thing you're announcing doesn't fall over.
Why you need a production checklist at all
Your product has been living in a forgiving world: a development database you can wipe and rebuild, security rules loosely enforced, generous error messages, no real user data at stake. Production is the opposite world — real people, real data, strict security, and no do-overs on a leaked key or a lost database.
The danger is that an app can look finished while being one unchecked box away from disaster. Everything on this list is invisible in a demo. All of it is existential in production.
The 14-point SaaS production checklist
This is the checklist I run before any product goes live, translated into plain language:
| # | Check | Why it matters |
|---|---|---|
| 1 | All database migrations run successfully | Production schema matches what your app expects — no missing tables on day one |
| 2 | Row-level security enabled on every table | The database itself refuses to serve one customer's data to another |
| 3 | Security policies tested, not just written | A policy that exists but is wrong feels identical — until the breach |
| 4 | Indexes created for performance | Queries that felt instant with 10 test rows crawl at 10,000 real ones |
| 5 | Authentication configured for your live domain | Sign-up and password-reset links must point at your real site |
| 6 | File storage buckets created with access policies | Uploads work — and users can only read their own files |
| 7 | Server-side functions deployed | Any backend logic actually exists in production, not just locally |
| 8 | Secrets set for those functions | Third-party keys live in secure settings, never in code |
| 9 | Email templates customised | Confirmation and reset emails carry your brand, not a generic default |
| 10 | Rate limiting configured | One abusive script can't hammer your login or run up your bill |
| 11 | Backups verified as running | Automatic daily backups exist — confirmed, not assumed |
| 12 | Monitoring alerts enabled | You hear about error spikes and slow queries before users email you |
| 13 | Connection pooling, if needed | Many simultaneous users don't exhaust your database connections |
| 14 | API keys stored securely — never in code | A key in your repository is a key on the internet |
Every check is a question you can put to AI: "Show me that row-level security is enabled on every table, and list the tables where it isn't." You don't need to know how to fix each item by hand. You need to refuse to launch until each answer is yes.
12 weeksYour corporate career was never the planApply to the Solopreneur Accelerator.Apply now →The three checks founders most often skip
Row-level security (checks 2 and 3). This is the wall between your customers' data — the database refusing, at its own level, to hand user A's records to user B. It's the check with the worst failure mode, which is why it gets its own guide. Enabled is not enough; test it by trying to read another account's data and confirming you can't.
Secret keys (checks 8 and 14). Your app has public keys (safe in the browser) and secret keys (full access to everything). The secret ones belong in your hosting provider's protected settings. If a secret key has ever been written into your code, treat it as compromised and rotate it before launch.
The rollback rehearsal. Not on the list above because it's a drill, not a setting: deploy, then practise reverting to the previous version from your hosting dashboard. It takes about 30 seconds with zero downtime — but only feels like a safety net once you've done it. That rehearsal is the foundation of deploying without fear after launch, too.
Hosting-side checks: domain, SSL, environment
On the hosting side, four items round out go-live. Your custom domain is connected — DNS changes take 10–30 minutes to propagate. SSL is active, which your host issues free and automatically in 5–10 minutes; no user should ever see a "not secure" warning. Production environment variables are set in the dashboard with real values, separate from any staging values. And error tracking plus analytics are switched on, so from your very first user you can see what breaks and what gets used — the same plumbing behind monitoring your SaaS as a solo founder.
Backups and recovery: assume the worst once
On the free tier of a platform like Supabase, backups run daily and are kept for 7 days. The Pro tier ($25/month) extends retention to 30 days and adds point-in-time recovery — restore your database to any moment, such as five minutes before a bad change. Spend ten minutes writing down your recovery plan while calm: database corrupted → restore latest backup and verify. It reads as paranoia until the day it reads as genius.
What all this costs: usually nothing
The reassuring part. The free tiers are genuinely production-grade: my own setup runs 3 production sites on 300–500 builds and 50–100 GB of bandwidth a month — for €0 in hosting. The signals you've outgrown free are concrete: a database over 500 MB, bandwidth past 5 GB/month, or wanting the longer backup retention — and then it's $25/month. For most solo products, the free tier carries you for months or years. The checklist costs an afternoon. Skipping it can cost the business.
The bookThe Solopreneur RevolutionLuis Gonçalves on building a solopreneur business with AI while employed.Get the book →Frequently asked questions
What should I check before launching a SaaS?
Fourteen technical items across five areas: database (migrations run, row-level security enabled and tested, indexes in place), authentication (configured for your live domain, branded emails), security (secret keys out of code, rate limiting), resilience (backups verified, a rehearsed 30-second rollback), and visibility (error tracking and monitoring alerts on).
Do I need a paid plan to go live?
Usually not. Free tiers are production-grade: unlimited bandwidth on the hosting side, daily backups with 7-day retention on the database side. Upgrade to the $25/month database tier when you pass 500 MB of data or want 30-day retention with point-in-time recovery. My own three production sites run on €0 of hosting.
What's the most commonly missed check?
Testing row-level security — not just enabling it. Founders switch it on, see no errors, and ship. But a wrong policy behaves exactly like a right one until someone reads another customer's data. Before launch, actively try to access data across accounts and confirm the database refuses.
How do backups work for a solo founder?
Automatically, once verified. Managed platforms back up your database daily with no configuration — 7-day retention free, 30-day plus point-in-time recovery on the $25/month tier. Your job is two-fold: confirm backups are actually running before launch, and write down the restore procedure while nothing is on fire.
How trapped are you, really?
Take the Corporate Suffocation Index, the free solopreneur readiness assessment.