There's a specific kind of dread that hits after you click "Deploy to Live" — the sense that something you didn't check is about to be the first thing a stranger finds. This checklist is ordered by consequence, not by how the Bubble editor happens to lay its tabs out. Start at the top. The first three items can leak data or break payments; the last few just look unpolished. Fix in that order.
1. Privacy rules on every data type — not just the sensitive-looking ones
This is the one that doesn't just embarrass you, it can leak data. Bubble's own security checklist is explicit: privacy rules need to be set on every data type that shouldn't be fully public, and the default state for a new data type is not locked down by default the way people assume. It's easy to lock down the obvious one (Users) and forget a secondary type — invoices, submissions, internal notes — that references user data through a field.
The fast way to check yourself: open your live app in an incognito window, open the browser's dev tools, and look at the network requests as you navigate. If you can see full records of data types that aren't meant to be public — other users' rows, unpublished content, internal fields — your privacy rules aren't doing their job yet. Bubble's checklist also flags that the page's underlying data (page names, data type names and default values, option set details, API Connector configuration) is visible in the page's JavaScript source to anyone who looks — normal and expected, but worth knowing before you're surprised by it.
2. Sensitive data isn't sitting in page elements, workflows, or URL parameters
Two related habits that are easy to pick up while building fast and forget to undo before launch:
- Debug values left in element content or workflow steps. A "Only visible to me" state you toggled off, an admin email hardcoded into a "send test notification" action, a coupon code you were testing with — anything typed in during development that shouldn't ship.
- Sensitive values in URL parameters. If your app passes anything identifying (an email, an internal ID meant to stay private, a token) as a plain URL parameter, it ends up in browser history, server logs, and anything that previews link content. Bubble's own guidance calls this out directly as a launch risk, not a style preference.
3. You're actually testing the Live version, not the Development version
Bubble keeps Development and Live as separate environments by design, and — per Bubble's version control documentation — only the Main branch can be deployed to Live at all (aside from a single hotfix branch, capped at one at a time). It is completely possible to test a flow thoroughly in the editor's Development version, deploy, and discover Live behaves differently — different API keys, different email-sending settings, different third-party plugin configuration, or a workflow step that was disabled in one environment and not the other.
After every deploy, re-test your core flow (signup, main action, any payment step) directly on the live URL, logged out, in a fresh browser profile — not the editor's preview.
4. API keys and plugin credentials are the live keys, not the test/sandbox ones
If you're using Stripe, an email service, or any API-connected plugin, double-check which credentials are wired to your Live version specifically. Test-mode keys silently succeeding in an environment that looks live is one of the most common "why didn't anyone actually get charged / get the email" bugs — because nothing throws an error, it just quietly does nothing real.
5. Custom domain and DNS are actually propagated — don't launch on a countdown
If you're moving off the default .bubbleapps.io subdomain, Bubble's own guidance on custom domain setup notes DNS verification can take up to 48 hours after you make the DNS changes. If you're coordinating a launch post or an email blast, this is the one item that has a clock on it independent of how fast you work — start it two days before you plan to announce anything, not the morning of.
6. SEO and social preview fields are filled in, not left on Bubble's defaults
Under Settings → SEO/metatags, Bubble lets you set a page title, meta description, and share image per page. Skipping this means your app's link preview in Slack, iMessage, or a forum post shows either nothing useful or a generic placeholder — which is a small thing, except it's often the very first impression anyone gets of your app, before they've even clicked through.
7. The responsive layout actually holds up on a real phone, not just a resized browser window
Test on an actual phone, not just a narrower desktop browser window — real mobile Safari/Chrome handle viewport height, on-screen keyboards, and tap targets differently than a resized desktop window simulates. The most common failure here isn't a broken layout, it's a layout that "works" but requires more scrolling or more precise tapping than a first-time mobile visitor will tolerate for ninety seconds of patience.
8. Someone who has never seen the app tries the actual first-run flow, live, out loud
Everything above is checkable alone. This one isn't. Sit next to someone — or watch a screen-share — while they open your live app cold and try to do the one thing it's for, with no explanation from you. You will learn more from their confused pause in the first ten seconds than from another hour of your own testing, because you already know what every button does.
Want that outside read without finding a person to sit with? Send in screenshots of your app's first-run flow for a free roast — a blunt, specific read on where a stranger actually stalls, usually back in your inbox within a few hours. Free, no account needed. There's also a €19 one-off pre-launch audit if you want a deeper pass, but the free roast doesn't require it.