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.
