Two launch bugs do most of the damage in a new SaaS: one customer can read another customer's data, and someone gets paid features without paying. Both look fine in the UI. Both show up the moment you send the request yourself, with the wrong account's token or without a valid Stripe signature.
TL;DR
Before launch, run four tests by hand: read another tenant's records with a second account's token, send an unsigned request to your Stripe webhook, call a paid endpoint from a free account, and check access after a cancelled subscription. Each takes under 15 minutes. The 20-item checklist below covers the rest.
The four tests to run before your first paying customer
A checklist tells you what should be true. These tell you whether it is. Run them against staging with real data shapes, then once more against production on launch day.
1. Read another tenant's data
Create two accounts in two separate organizations. Log in as account B, copy its session token or JWT from the browser's dev tools, and request a record that belongs to account A:
# Replace with a real record ID owned by account A
curl -i https://yourapp.com/api/projects/A_PROJECT_ID \
-H "Authorization: Bearer $ACCOUNT_B_TOKEN"
Anything other than a 403 or 404 is a launch blocker. Repeat it for every route that takes an ID: projects, invoices, files, team members. AI-generated apps very often check that you're logged in and never check that the record is yours.
If you're on Supabase, test the database directly too, because the browser talks to it without going through your API:
curl "https://YOUR_PROJECT.supabase.co/rest/v1/projects?select=*" \
-H "apikey: $SUPABASE_ANON_KEY" \
-H "Authorization: Bearer $ACCOUNT_B_JWT"
You should only get account B's rows. If you get everyone's, row-level security is off or its policy is too broad.
2. Send your Stripe webhook an unsigned request
Your webhook is a public URL. If it doesn't verify the Stripe-Signature header, anyone can tell your app a payment succeeded.
curl -i -X POST https://yourapp.com/api/webhooks/stripe \
-H "Content-Type: application/json" \
-d '{"type":"checkout.session.completed","data":{"object":{"customer":"cus_fake"}}}'
The right answer is a 400. A 200 means the handler parsed the body without calling stripe.webhooks.constructEvent() (or your framework's equivalent) against your signing secret. Then confirm the real path still works with the Stripe CLI: stripe listen --forward-to localhost:3000/api/webhooks/stripe in one terminal and stripe trigger checkout.session.completed in another.
3. Call a paid feature from a free account
Hiding a button isn't enforcement. Log in as a free user, open the network tab on a paid user's session to find the request a paid feature makes, and replay it with the free user's token. If it succeeds, your plan check lives only in the frontend. Move it to the server, next to the code that does the work.
4. Cancel, then try again
Subscribe a test account, cancel it in the Stripe dashboard, and wait for the customer.subscription.deleted event to land. Then use the account. If paid features still work, your app is reading a stale plan value it never updates. This one rarely gets caught in testing because nobody cancels during development.
Keep the two test accounts after launch. Re-running tests 1 and 3 takes five minutes and is the fastest way to catch a regression after the AI rewrites an API route.
The full pre-launch checklist
Authentication and Access 5
Data Protection 5
Payments and Billing 4
Infrastructure 3
Operations 3
What security do I need for a SaaS MVP?
At minimum: proper authentication, data isolation between customers (multi-tenant), HTTPS, secure payment processing, and a way to respond to security issues. These are non-negotiable before accepting paying customers.
Do I need SOC 2 compliance before launching a SaaS?
No. SOC 2 becomes relevant when selling to enterprises that require vendor security reviews. Focus on the fundamentals first. Most early-stage SaaS products can launch without any compliance certification.
How do I test multi-tenant data isolation before launch?
Create two test accounts and try to access account A's data while logged into account B. Test every API endpoint, not just the UI. If your database uses row-level security (like Supabase RLS), verify the policies with a direct database query using account B's credentials. Many leaks show up only at the API layer.
What happens if I launch with a security issue?
Depends on the issue. A broken login flow is recoverable. Leaking one customer's data to another customer is not. You'll face immediate churn and potential GDPR/CCPA liability. Multi-tenant isolation and exposed API keys are the two issues most likely to cause real damage at launch, so start there.
Find security issues in your SaaS before your customers do.