SaaSChecklist
daLæs på danskSaaS Launch Checklist: 30 Things to Check Before You Take Payments
A SaaS launch checklist with 30 checks for billing, EU VAT, email deliverability, backups, monitoring and terms before your first paying customer.
Freelance full-stack developer
- Published
- Reading time
- 8 min
In this post9
Before you open your SaaS to paying customers, six areas need to be ready: billing and VAT, transactional email, data and backups, monitoring, legal terms and support. This SaaS launch checklist breaks them into 30 concrete checks you can tick off one at a time. Each protects money, data or customer trust in your first weeks live.
The short answer: 30 checks in six areas
| What breaks if it's missing | The one check not to skip | |
|---|---|---|
| Billing and VAT | Customers aren't charged, or VAT is wrong | One real payment in live mode |
| Confirmations and password resets go to spam | SPF, DKIM and DMARC on your domain | |
| Data and security | Data loss, or customers seeing each other's data | A restore you've actually tested |
| Monitoring | Customers notice downtime before you do | Alerts routed to a named person |
| Legal and GDPR | EU business customers can't sign off | A data processing agreement ready to sign |
| Support and metrics | You can't tell why trials don't convert | A stranger has tested your sign-up |
My rule of thumb: features can wait, billing and data can't. See my list of MVP features you can skip at launch, and the guide to building a SaaS for the full path from idea to first customer.
Billing and EU VAT: checks 1-5
Here a bug costs money directly. Test mode at Stripe or Paddle behaves almost like production, but only almost.
Billing and EU VAT
- 1. Every billing path is tested: sign-up, plan change, failed payment, card update and cancellation.
- 2. Live webhooks work: the notifications your provider sends your app (webhooks) are signature-verified, and one that arrives twice or out of order doesn't double anything.
- 3. Live mode is ready: live keys sit only on the server, prices exist in live mode, and you've made one real payment with your own card and refunded it.
- 4. Failed payments have a plan: you know how long a customer keeps access after a declined card, and what they see.
- 5. VAT and invoices are right: reverse charge with a validated VAT number for EU business customers, local VAT where it applies, and your company details on every invoice.
Stripe's own go-live checklist adds rotating your API keys and testing with duplicate data. If you're established in the EU and sell to consumers in other member states, you charge VAT at the customer's rate once those sales pass €10,000 a year, usually through the EU One Stop Shop. If you're established outside the EU, that threshold doesn't apply. A merchant of record like Paddle takes most of this off your plate (see my comparison of SaaS subscription billing providers). Have an accountant check your setup.
Transactional email that arrives: checks 6-10
Your SaaS sends emails people wait for: confirmations, password resets, invites and receipts. If they don't arrive, the product looks broken even when the code works.
Transactional email
- 6. Email goes through a delivery service: Postmark, Mailgun, Amazon SES or similar, never straight from your app server.
- 7. Your domain is authenticated: SPF, DKIM and DMARC are set in DNS for the domain you send from.
- 8. Every system email is reviewed: copy, sender and links, with nothing pointing at staging, including emails that only fire on errors.
- 9. Inbox placement is tested: sent to Gmail and Outlook addresses and checked for the spam folder.
- 10. Replies reach a human: the reply-to address goes to an inbox someone reads, and bounces are tracked.
Google's sender guidelines require SPF or DKIM from everyone sending to Gmail, plus DMARC once you send more than 5,000 messages a day. I recommend all three from day one. Setup usually takes under an hour, and it's much harder to fix once mailbox providers decide your domain sends spam. Keep marketing email on its own subdomain.
Data, security and backups: checks 11-15
These are the mistakes you can't undo. A business customer who has seen another company's data rarely stays.
Data, security and backups
- 11. Automated off-site backups: the database is backed up at least daily, and copies live somewhere other than the app server.
- 12. A restore has been tested: you've restored a backup into a separate environment and know how long it takes.
- 13. Files are covered: user uploads such as images, PDFs and attachments are backed up, not just the database.
- 14. Tenants are isolated: test accounts in two different companies try to reach each other's data through URLs and the API, and fail.
- 15. Production is locked down: debug mode is off, logins are rate limited, and hosting, billing, DNS and GitHub use two-factor authentication.
Debug mode is the classic: in Laravel, APP_DEBUG=true in production can show visitors sensitive details about your configuration. For a 3-2-1 setup and a step-by-step restore test, see my web app backup strategy.
Monitoring and deployment: checks 16-20
Launch surfaces bugs no test caught. Will a tool tell you, or an annoyed customer?
Monitoring and deployment
- 16. Uptime is monitored: UptimeRobot, Oh Dear, Better Stack or similar alerts you when the app goes down.
- 17. Errors are reported: Sentry, Flare or similar captures exceptions with enough context to fix them.
- 18. Background jobs are watched: queues and scheduled tasks such as invoicing and email sending raise an alert when they stop.
- 19. Deploys are repeatable: a release ships with one command or click, and you know how to roll back.
- 20. Domain and certificate renew themselves: the domain is registered to the company, and both it and the TLS certificate auto-renew.
The tool matters less than who gets the alert, evenings and weekends included. Watch the queue in particular: when it stalls, the app looks fine while emails and invoices quietly pile up.
Terms, privacy and GDPR: checks 21-25
EU business customers often ask for your terms and a data processing agreement before they ask about features. Without them, the deal can stall in procurement.
Terms, privacy and GDPR
- 21. Subscription terms: billing, cancellation, price changes, liability limits and what happens to data when a customer leaves.
- 22. Privacy policy: what personal data you process about users, why, for how long and with which vendors.
- 23. Data processing agreement: a standard agreement customers can accept, since you process personal data on their behalf.
- 24. Sub-processor list: hosting, email, payments, error tracking, support and analytics, and where each stores data.
- 25. Company details and cookies: legal name, address, email and registration number are visible, and analytics or ad cookies wait for consent.
As a processor, you need a written contract with each customer under Article 28 of the GDPR, and customers must get the chance to object to new sub-processors. EU e-commerce rules also generally require business websites to show company details (in Germany, the Impressum). Selling to consumers adds rules such as withdrawal rights. This isn't legal advice, so have a lawyer review your terms. The technical side, like export and deletion, is in my GDPR checklist for SaaS.
Support, onboarding and metrics: checks 26-30
Make it easy for your first customers to get started, get help and leave.
Support, onboarding and metrics
- 26. A stranger has tested sign-up: someone who has never seen the product gets from sign-up to a first result without your help.
- 27. There's a support channel: customers know where to write and when to expect a reply.
- 28. You have an admin view: you can find a customer, extend a trial and issue a refund without touching the database.
- 29. Customers can cancel and export: cancellation and data export work, and you've decided when data is deleted.
- 30. You track what matters: sign-ups, activation, payments and cancellations show up somewhere you actually look.
Check 26 is cheap and catches more than most tests: give someone a task and say nothing. More ideas for a user's first minutes are in my SaaS onboarding best practices.
Next steps: from checklist to launch day
Mark every item as done, missing or deliberately postponed. Postponing a status page is fine, as long as it's a decision rather than something you forgot.
You can handle plenty of this yourself: terms, support, the sign-up test and the email review. If you built on a no-code tool with billing and hosting included, many technical checks are already covered, and a developer is rarely worth the money right before launch. Get help with webhooks, tenant isolation and backups if you can't test them yourself, because those failures stay invisible until they cost you.
For help with the technical checks or finishing the product, here's how I approach SaaS development. You talk directly to me, and you own the code from day one.
Frequently asked questions
How far ahead of launch should I start this checklist?
Start two to four weeks before launch. Most checks are quick, but some depend on others: DNS changes, payment account activation and a lawyer's review of your terms can each take days. Begin with billing and legal, and leave the sign-up test until the product has stopped changing every day.
Do I need to host my SaaS in the EU?
Not strictly. The GDPR allows transfers outside the EU with appropriate safeguards. In practice, EU hosting makes your data processing agreement and sub-processor list simpler, and fewer procurement questions come back. If most of your customers are European, pick an EU region from the start, because moving later means a migration.
Do I need a penetration test before launch?
Rarely before your first customers, unless you handle sensitive data such as health or financial records, or a large customer requires one. Most new SaaS products get more from working through checks 11-15 carefully and having a developer test tenant isolation. A pen test is most useful once the product is more stable and customers start asking for it.