How to Launch Your Bubble.io SaaS: The Pre-Launch Checklist
Going from ‘working in development’ to ‘live for paying customers’ requires more than clicking Deploy. One missed privacy rule, one unsigned webhook, one untested billing edge case — any of these can become a customer-facing disaster. This checklist prevents all of them.
Security — The Non-Negotiables Before Any Public Launch
- ✓
Every data type has at least one privacy rule — zero types remain on “Everyone”
- ✓
Every app data type has a workspace field populated on creation in every single workflow
- ✓
Every search in every workflow and page has workspace = current_workspace as first constraint
- ✓
Tenant isolation tested with two isolated browser sessions — different workspaces see zero data from each other
- ✓
User data type: users can only see co-members, not all users in the system
- ✓
All destructive workflows have server-side role checks — not just UI-level button hiding
- ✗
File uploads not accessible via public direct URLs without authentication
- ✗
No sensitive data (API keys, tokens) stored in visible-to-user fields
Billing — Every Edge Case Must Be Handled
- ✓
Stripe webhook signature validation enabled on every event handler
- ✓
All six webhook events handled: checkout.completed, subscription.updated, subscription.deleted, payment_failed, trial_will_end, payment_succeeded
- ✓
Subscription status updated ONLY from webhooks — never from the success redirect URL
- ✓
Cancelled workspaces are read-only with all data preserved — not deleted
- ✓
Seat and record limits enforced in both UI conditions and server-side workflow guards
- ✓
Plan downgrade tested: workspaces exceeding new limits show degraded state gracefully
- ✓
Trial-ending email tested — fires 3 days before trial expiry with correct personalisation
- ✓
Stripe Customer Portal enabled for self-serve payment method updates
Performance — Test Under Real Conditions Before Launch
- ✓
Zero :filtered by expressions — all filtering uses database search constraints
- ✓
All repeating groups paginated to maximum 20 records per page
- ✓
All static data (statuses, roles, categories) uses Option Sets — not data types
- ✓
Dashboard load tested with 500+ records — under 2 seconds on a mobile connection
- ✓
Bubble app on Growth plan or above — no production SaaS on shared Starter server
- ✓
Every data type has is_deleted (yes/no) for soft deletes — no hard deletes in production
The Launch Day Sequence
Sign up a test account, create a workspace, go through onboarding, subscribe via Stripe test mode, invite a team member, create a record, and cancel the subscription. Every flow must work end-to-end before you tell anyone it is live.
Update API keys from test (sk_test_) to live (sk_live_). Update webhook endpoints in Stripe dashboard to point to your production Bubble app URL. Verify the first live checkout with a real card before announcing publicly.
Do not rely on self-serve for the first 10. Get on a video call with each one. Watch where they get confused. These 10 sessions will tell you more about your product than any analytics tool. Fix the top 3 friction points before announcing to a wider audience.
Install a session recording tool (Hotjar or FullStory). Set up error alerting (Bubble logs + Slack notification for failed workflows). Configure uptime monitoring. You should know about a problem before your customers email you about it.
Ready to Build on Bubble?
Architecture, data model design, Stripe billing, and full SaaS builds — done right from day one.
