Bubble SaaS Complete Checklist
The master reference for every stage of a Bubble SaaS — architecture, build quality, billing, security, and growth operations. The synthesis of 115 posts compressed into one actionable checklist to return to before every major milestone.
Everything You Need to Build, Launch, and Grow a Bubble SaaS
This is the complete reference checklist for every stage of a Bubble SaaS — from the first architectural decision to ongoing growth operations. It is the synthesis of every guide in this series, compressed into a single actionable reference. Bookmark this page. Return to it before every major milestone. The items you skip are the ones that become expensive problems later.
Before You Open Bubble
- ✓
Data model designed on paper: every type, field, and relationship documented before opening the editor
- ✓
User roles defined as an Option Set on the Membership record, not the User record
- ✓
Privacy rules planned for every data type — zero types will remain on Everyone
- ✓
Every app data type has a workspace field: required for multi-tenant isolation
- ✓
Plan limits stored in a Plan data type, not hardcoded in workflow conditions
- ✓
is_deleted (yes/no) field planned for every data type from day one
- ✓
Static data (statuses, categories, roles) assigned to Option Sets, not data types
While Building
- ✓
Zero :filtered by expressions — all filtering uses search constraints (WHERE clauses)
- ✓
Every sensitive workflow has a role check on Step 1 with an Only when condition
- ✓
Dashboard counts stored as denormalised fields on Workspace, updated on every relevant change
- ✓
Every search in every page and workflow has workspace = current_workspace as first constraint
- ✓
All repeating groups paginated to maximum 20 items per page
- ✓
Long-running operations use backend API workflows, not frontend workflows
- ✓
Every API call has an error-checking step immediately after it
Stripe Integration
- ✓
One Stripe Customer per Workspace (not per User)
- ✓
workspace_id stored in Stripe metadata on every Customer, Subscription, and Checkout Session
- ✓
All six webhook events handled: checkout.completed, subscription.updated, subscription.deleted, payment_failed, payment_succeeded, trial_will_end
- ✓
Stripe webhook signature validated on every incoming event
- ✓
Subscription status updated ONLY by webhooks, never by redirect URL
- ✓
Cancelled workspaces: read-only with all data preserved, not deleted
- ✓
Seat and record limits enforced in both UI conditions and Step 1 workflow guards
Before Launch
- ✓
Every data type has at least one privacy rule — zero types remain on default Everyone
- ✓
Tenant isolation tested: two isolated browser sessions, zero cross-workspace data leakage
- ✓
Stripe keys switched from sk_test_ to sk_live_ and webhook URL updated to production
- ✓
Custom domain connected, SSL active
- ✓
Bubble app on Growth plan or above (dedicated server for production)
- ✓
Session recording installed (Hotjar or FullStory) to observe first users
- ✓
A live end-to-end test with a real Stripe card completed before announcing launch
Post-Launch Operations
- ✓
One customer conversation per day — non-negotiable daily habit
- ✓
One session recording reviewed per day
- ✓
Onboarding email sequence live and sending automatically on workspace creation
- ✓
Monthly churn rate tracked and documented
- ✓
Churn interview within 48 hours of every cancellation
- ✓
Weekly LinkedIn or content post (distribution is a daily habit, not a campaign)
- ✓
NPS survey sent at day 30 to paying customers, PMF score tracked
- ✓
Annual billing conversion actively promoted in billing settings and upgrade flows
- ✗
Never add a new feature before validating that the current ones are being used
- ✗
Never scale acquisition before monthly churn is below 5%
Ready to Build on Bubble?
Data model design, Stripe billing, multi-tenant architecture, and full SaaS builds — done right from day one by Pakistan’s leading Bubble.io team.
