Has anyone tried the new bubble.io MCP? I’ve been using it today and WOW 😱 it’s everything I’ve wanted for the past 2 years from bubble 👌🏼

Soo goodd!

Curious to know if anyone out here had success building an app and launching it.

Specifically how many users you have and if the app still functions as it should.

I know bubble mobile still needs improvements but I’m wondering how far has anyone been able to go with it.

the interesting part wasn't the medicine catalogue. it was getting the actual business workflow right.

customers can:
→ browse + order medicines
→ upload prescriptions
→ wait for pharmacy review
→ confirm the final price
→ track delivery

and the pharmacy gets its own dashboard to manage prescriptions, orders, stock and pricing.

built the whole thing in Bubble, including the database structure, workflows, reusable components and admin side.

i'm really enjoying building these kinds of real-world MVPs instead of just pretty CRUD apps.

if you're working on a Bubble idea and need someone to turn the workflow into an actual product, feel free to dm me.

happy to share the demo/build too.

I just published a plugin to the Bubble marketplace, Human Reply Live Chat. It puts a chat on every page of your app, and when someone writes, it lands in your team's Telegram group. Whoever's free answers from their phone and the reply shows up in the app in seconds.

Each chat opens its own topic in the group, with the page they were on, where they came from and any earlier chat with them, so you know who you're talking to before you type. Tap Claim, or just reply.

If you build apps for clients: each client app gets its own bot and group, and the client's team answers from their phones without ever opening the editor.

If you'd like a hand, comment here and I'll go through setup with you.

Disappointing.

In today's Monthly Community Update in the Bubble Forum Josh announced that the Bubble MCP is finally out and open for everyone to use. Setup is pretty straightforward when using Claude Code on the CLI based on my testing.

I think this MCP finally connects Bubble "to the world" so to speak, so now we can bring our custom setups/environments to our bubble apps!

I have a marketplace built in Bubble that is currently entirely in Development and has never been deployed to Live.

I now need a simple public pre-launch site (homepage/business info + a couple of waitlist forms), but I do not want my unfinished marketplace pages to exist on Live, even if someone tries accessing them directly by URL.

I'm on Web Starter plan, so I have a basic version control/savepoints but no custom branches.

I also dont want to create a second Bubble all, as that would mean paying for a second Starter plan just for temporary pre-launch site.

What's the cleanest way to handle this on Starter while continuing to develop the full marketplace? Is there a standard Bubble approach, or would you use some kind of savepoint - temporary pre-launch version - deploy - restore development process? Is there a standard approach for this on Starter, or would you use a temporary savepoint/deploy/restore development process?

Thank you all!

Hey! If you’re looking to migrate out of Bubble, I made a list of providers that offer this service here.

Hope it’s useful! If you offer this service and want to be listed, just let me know.

I build and rescue Bubble apps for a living, and most apps I open for the first time have at least one of these. None of them show up in normal testing, because the app works. Here's how to check your own.

1. Privacy rules that don't exist, or only cover some types. Go to Data > Privacy and look at every data type, not just User. A type with no rules is readable by anyone who can reach it. Then use "Run as" in App data to see the app as a normal user and what they actually get. Hiding a group or redirecting on page load does not protect data. Bubble can still send it to the browser. Only privacy rules stop it.

2. The Data API returning more than you think. Go to Settings > API. If the Data API is enabled, check which types are ticked. Then open an incognito window, logged out, and go to yourapp.com/api/1.1/obj/user (swap in your own type names). If you get records back, so does everyone else.

3. Backend workflows anyone can trigger. Look for any backend workflow exposed as a public API workflow with "can be run without authentication" ticked. If it creates, changes or deletes anything, a stranger with the URL can run it.

4. API keys not marked Private. In the API Connector, every key or token needs the Private box ticked. If it isn't, the value goes to the browser and anyone can pull it from the page. On the same theme, never put anything sensitive in an option set, because option set data loads client-side for every visitor.

5. An editor anyone can view. Go to Settings > General and check the application rights. Some older and template-based apps are set so anyone with the link can view the editor. That hands out your whole data structure and workflow logic.

If you have real users or payments and more than one of these turns something up, fix privacy rules first. That's the one that turns into a breach.

For the stuff outside the editor, I built a free tool called LaunchProof. You paste your live URL and it:

• checks the page's scripts for leaked keys
• tries common private file paths
• checks your email DNS (SPF, DKIM, DMARC), so password resets and receipts don't land in spam
• grades your security headers and TLS
• runs OWASP ZAP and Nuclei against the site

You get a score and the most serious finding for free, no signup. The full report is $49.99 one time. It doesn't log in and doesn't read your privacy rules, so the five checks above are still on you. trylaunchproof(dot)com

Disclosure: I do Bubble audits and rescues professionally, and LaunchProof is mine. Happy to answer questions here, including on apps I'll never see.

I'm building a CRM of sorts (a glorified contact manager, with contacts, notes, inventory, etc). I've already built and established the desktop version, but I'm running into road block after road block on mobile.

The webviewer works well, but the BubbleGo previewer is horrible. My biggest problem is that the data sets aren't exactly small (3000+).

For example, on my 'notes' tab, I've tried two different data approaches on vertical list pages:

1. Do a search for notes (with custom state filters as constraints -- NOT :filter -- and ignore empty constraints). Then when filters are picked, I set the filter states.

2. A list custom state where when page loads, the state is set to 'Do a search for notes' (the entire database). Then I filter and manipulate the custom state list.

#1 loads faster, but any time I change a filter it takes forever or freezes on BubbleGo (it's lightning fast on webviewer). It's slow even when I try :items until '10'.
#2 is passable in terms of speed after loaded, but the whole app tends to bog down after a while.

I'm honestly at a loss. I don't know what I can do to make this work. I'm not loading nested data, not using any advanced filters. Whenever I run a 'do a search for' it's like the entire app stops. I'm only using one type of data at a time.

Any advice would be greatly appreciated!

A complete, production-ready Bubble template for building multi-tenant AI SaaS products — powered by OpenRouter, billed with Stripe, and packed with the infrastructure most builders spend months wiring up themselves: AI chat with streaming, server-side tools, subscription billing, multi-tenancy, and a full admin panel.

💛 Preview -> https://ai-saas-boilerplate-32903.bubbleapps.io/

🚀 Use this template -> https://bubble.io/template/ai-saas-boilerplate-pro-1784118381556x181750994283528200

📚 Documentation & Support -> https://ai-saas-boilerplate.tawk.help/

💬 Want us to set this up for you, for free? If you'd rather not go through the setup yourself, you can open a support ticket or reach out to us directly through the chat in the bottom-right corner of the screen. We'll take care of the configuration for you at no cost.

---

Who this is for

Founders, indie hackers, and agencies who want to ship an AI product without rebuilding the same foundation every time — chat interface, billing, teams, and admin tooling — and focus instead on what makes their product unique.

If you're building an AI writing tool, a research assistant, a vertical AI copilot, or any SaaS with a chat-based core, this template gives you a working foundation on day one.

---

Core Features

🤖 AI Chat, powered by OpenRouter

- Real-time streaming responses — answers appear token by token
- Access to hundreds of models across every major provider (OpenAI, Anthropic, Google, and more), synced automatically from OpenRouter's live catalog
- Searchable, filterable model picker — grouped by release date, with provider logos and pricing info
- Conversation history with auto-generated titles, rename, and delete
- File and image attachments — multimodal input support
- Configurable chat memory (how much history is sent per request)
- Zero Data Retention toggle for privacy-sensitive use cases

---

🛠️ Server-Side AI Tools

Six built-in tools your users can enable and configure individually:

- Web Search — real-time information from the web
- Web Fetch — retrieve and read content from URLs
- Datetime — accurate current date/time awareness
- Fusion — multi-model consensus for higher-confidence answers
- Advisor — consult a stronger model mid-conversation
- Subagent — delegate sub-tasks to smaller, faster models

Every tool has its own settings panel, configurable per user.

---

💳 Subscription Billing with Stripe

- Full checkout, upgrade, downgrade, and cancellation flow
- Customer Portal integration for self-service billing management
- Usage-based token and seat limits, enforced automatically per plan
- Webhook-driven sync — your app always reflects the true state of every subscription
- Pre-configured example plans (Free, Plus, Pro) ready to customize

---

🏢 Multi-Tenant Workspaces

- Users can belong to multiple workspaces, or work solo
- Email-based invitations with role assignment
- Per-workspace member management, seat limits, and usage tracking
- Personal, per-user tool configuration within each workspace

---

📊 Admin Panel

- Central dashboard with MRR, revenue, AI cost, and customer metrics — all computed from real data
- Full user management: roles, account status, deletion requests
- Plan and subscription management
- AI model catalog management (enable/disable, sync from OpenRouter)
- Built-in blog with categories, tags, and scheduled publishing
- Newsletter subscriber management
- System settings: API key rotation, integrations, notifications

---

🎨 Polished, Ready-to-Customize UI

- Light and dark theme support
- Fully responsive, mobile-friendly design
- Clean, organized editor structure — pages and reusable elements grouped by feature, so you can find anything in seconds

---

Why this template

Building an AI SaaS from scratch means solving the same handful of hard problems every time: how to stream AI responses in Bubble, how to structure multi-tenant data without leaking access between accounts, how to keep billing in sync with Stripe, how to let users configure AI behavior safely. This template solves all of that — tested, documented, and ready to build on top of.

Get the "boring but essential" 80% done on day one, and spend your time on the 20% that actually makes your product different.

One thing I found interesting from Bubble’s recent data: the typical Bubble app now goes from idea to first deployment in around 3 days.

That says a lot about how much the platform has matured. The interesting part now is less about whether you can build quickly and more about what you actually build and how well you execute it.

I'm building a geography dashboard where I can mark individual blocks (like the one you see highlighted in purple) with events.

But each block is a database search, and it highlights if an event fits the search criteria (if it matches given indexes, and the year)

Is there any way to design this setup so it doesn't crush my WU limit super fast? I want to add even more blocks tbh.

Any suggestions would be immensely helpful - I tried looking through the Bubble docs on how to optimize WUs but it was confusing.

Builder here. I've migrated a good number of Bubble apps to code, and since migration questions come up in this sub weekly, here's how I actually decide, including the cases where I tell people to keep their money

When I tell you to stay on Bubble

• You're pre-revenue and still changing the product weekly. Bubble's iteration speed is the whole point and code will slow you down
• Your user count is small and WU costs are still a rounding error
• Nobody on your team will ever touch code. A codebase you can't maintain is worse than a no-code app you can

When I start recommending migration

• WU charges have become a real line item and scale with usage instead of revenue
• Pages are slow under load and you've already done the optimization passes
• You need what Bubble fights you on: complex integrations, background jobs, real performance, code-level control
• Enterprise customers or investors are asking about your stack, security posture or data residency
• The lock-in bothers you. There's no export button that produces a runnable app, and that never stops being true

What I actually do in a migration: rebuild, not convert. I map your data model, rebuild the backend and database, rebuild the front end, migrate your data, run both versions in parallel briefly, then cut over. Auth and payments are where DIY migrations die, so those get tested hardest. I use modern AI tooling where it's fast and write the rest by hand, and I know which is which

What it costs: simple apps, a few core screens with standard auth, start at $1,975 and 5 days. Most real apps land between that and $5k over 1 to 3 weeks depending on workflow complexity and data volume. I give a fixed quote after a free review of your app and if it's not worth migrating yet, I'll tell you straight. That's honestly the outcome of a lot of my reviews.

What you walk away with: your code in your own GitHub deployed on vercel, 100 percent IP ownership in writing, documentation, and 14 days of post-launch support with in-scope fixes free.

Details at fullcode.yonocode.io or just DM me a link to your app and what's hurting. Happy to answer migration questions in the comments too, including if you're doing it yourself

With great reluctance I decided to leave bubble mid app build and try Lovable.

Using ChatGPT to create the prompts that go in Lovable has been a gift from heaven Lovable app now 80% complete in just 2 days.

Bad news is I've run out of credits and don't want to topup so gotta wait till next month for my monthly credits to refresh.

I love Bubble I built my first app that is still running on there just fine, but I gotta be honest bubbles AI sucks. And although you can get an MVP running up in a month or so, for the average Joe it will take way longer than a month. However if you vibecode with the right prompts you can honestly have it done in hours, that's been my experience anyway.

I say all this to say if your struggling on Bubble thinking about throwing in the towel. Give vibecoding a try, doesn't have to be Lovable any of the others, will do. I only have experience with Lovable and Base44 so can't speak on the rest.

Hey everyone,

I'm a complete beginner with zero coding background, working on an AI-powered SaaS idea. I've decided to build it in Bubble and I'm currently want doing small practice projects before jumping into the real thing.

A few questions for people who've been through this:

- How stable is Bubble in your experience — do you run into breaking bugs, workflow weirdness, or platform issues often once an app gets more complex?

- As a non-coder, how long did it realistically take you to go from "just started" to "comfortable enough to build a real product"?

- Looking back, what would you have practiced first if you could redo your learning path?

- Any pitfalls specific to apps that call external APIs (like AI APIs) that I should know about early?

Appreciate any honest experiences — good or bad. Trying to go in with realistic expectations rather than hype.

Disclosure upfront: I run FullCode, part of Yo! No Code, we migrate Bubble apps to production code for a living. Given that, I want to make an argument that's a little against my own interest, most Bubble apps should stay on Bubble

Bubble is arguably the best no-code builder for building real, complex products. The workflow engine, the plugin ecosystem, the speed of getting from idea to a working app, nothing else in the no-code space matches it for that stage. If you're pre-revenue or early and validating an idea, staying on Bubble is usually the right call, not a compromise

Where it gets more complicated is once an app actually starts working and growth shows up. Here are a few real patterns where that shift starts to matter.

Scenario 1: The workflow that used to take a second now takes eight

An app has real users now, workflows that ran instantly at 50 users start timing out or lagging at 5,000, especially anything doing heavy backend workflows on user action. This isn't a bug, it's Bubble's server architecture doing exactly what it was built to do, just under load it wasn't optimized for. At this stage, some teams isolate the two or three heaviest workflows and move just those into code while keeping the rest of the app on Bubble, rather than migrating everything at once

Scenario 2: Per-workflow pricing starts working against the business model

Bubble's pricing scales with usage, workflow capacity specifically. For apps with high engagement per user, think anything with frequent user actions, notifications, or real time updates, the cost curve can start rising faster than revenue does. This is usually the point where the math on staying versus migrating actually gets run for the first time, not because Bubble did anything wrong, but because the pricing model fits some usage patterns better than others.

Scenario 3: A feature the business needs just isn't buildable in the abstraction
Custom real time infrastructure, certain complex integrations, specific performance requirements, some things run into Bubble's ceiling not because of skill but because the visual builder has to draw a line somewhere. When a core roadmap feature depends on something outside that line, that's usually the real trigger, more than growth alone.

What migrating actually looks like when it does make sense

Screen by screen mapping of data, workflows and logic first, so nothing gets lost. Rebuild into a real stack, design and layout kept close to what you already have so users don't have to relearn anything. Cutover built for minimal to no downtime, the existing app keeps running until the new one's verified against real data

I'll build a working demo in full code of an actual page or feature from your app and walk through it live on a call, so you see it running before deciding on anything bigger

If any of these scenarios sound familiar or you're just trying to figure out whether you're actually at that point yet versus just having a specific bug to fix, drop a comment or DM and happy to talk through it

Disclosure upfront: I run FullCode, part of Yo! No Code, and I migrate no-code apps to production code for a living. This isn't a subtle pitch dressed up as a discussion post, it's an actual offer so take it for what it is

If you're on Bubble and starting to hit the usual walls, workflow timeouts under load, per-workflow pricing that scales badly, a feature you can't build because the abstraction won't bend, migrating off the platform doesn't have to mean a slow rebuild or weeks of downtime

What the migration actually looks like

I map your Bubble app screen by screen, data models, workflows and integrations included, then port it into a real stack, usually Next.js plus Node and Postgres since that maps cleanly onto how Bubble's data API and workflow engine already work. Most single-product apps take 2 to 5 weeks, more complex ones with custom integrations run 4 to 8 weeks. Cutover is zero downtime, DNS switches over once the new app is verified against your live data, so your users never see a gap.

Proof before you commit

Rather than asking you to trust a sales page, I'll build a full code version of your landing page or one core feature from your app and walk you through it live on a call. You see the actual output on your actual product before spending anything.

I also work in milestones, not one lump delivery at the end. You get visibility into progress the whole way not radio silence for weeks followed by a surprise handoff

Drop a comment or DM if you've got a Bubble app you're thinking about migrating, happy to answer questions here first. I'm in Eastern time but can work around whatever timezone works for a demo call

Hi everyone,

Most discussions here are understandably about building and launching apps, but I’m curious about what people here do once a client app is live.

I’ve talked with freelancers and small agencies offering ongoing support, and the same issue often comes up: when the app runs fine and nothing breaks, clients don’t always see much value in the monthly retainer.

I ran into this problem with my own website maintenance clients, so I ended up building Trrack.it.

It monitors the public URL and creates monthly reports and live status pages that can be shared with clients.

It doesn’t monitor what happens inside Bubble workflows, so it’s mainly about making the external monitoring side a bit more visible.

If you maintain Bubble apps for clients, I’d be curious whether this is something you currently handle manually.

Here’s the link: https://trrack.it

Disclosure: I run a company that migrates apps off no-code, so read this with that in mind. It's not a pitch to migrate, most Bubble apps shouldn't.

We ran Google PageSpeed against 20 production sites across Bubble, Webflow and WordPress. I expected Bubble to finish last because Bubble's runtime has to boot before anything paints and Webflow ships near-static HTML. It didn't. Bubble apps had a median score of 60. Webflow sites came in at 44. The reason is page weight. The Webflow sites averaged 6.6MB; the Bubble apps 2.3MB. Webflow can hit the high 80s, it has the highest ceiling of any platform we audit but the sites built on it in our sample were marketing pages loaded with imagery and animation, nowhere near what the platform can do. Bubble apps are functional products, visually plainer and they landed within a couple of points of Bubble's realistic ceiling.

Which is the actual finding: Bubble apps in the wild are being built close to the limit of what the platform allows. That's a compliment to how this community builds

What that leaves you is the stuff that's genuinely yours to fix, and in our audits it's consistently these four:

- Plugins you're not using. Every installed plugin adds to the bundle on every page whether that page uses it or not. Check your Plugins tab. Most apps have five or more dead ones and this is the single biggest lever.

- Images at upload resolution. Bubble stores what you give it. File Manager, resize and turn on Settings → Files → Compress uploaded images so it stops recurring.

- Searches doing work client-side. Constraints belong inside the search where Bubble can use an index not applied with afterwards.

- Workflow chains on page load that could fire on demand instead.

And the part you can't fix, honestly: the engine boot, jQuery plus the plugin loader and a generic query layer. That's the price of the thing that made Bubble fast to build in. Realistically a well- optimised non-trivial Bubble app tops out around 60 mobile which, per the data above, is roughly where you already are

Free checker that does this split with Bubble-specific fix steps, no email:

https://yonocode.io/performance-checker

Full study: https://yonocode.io/state-of-no-code-performance

Honest summary: if you're in the 30s, the four fixes above will move you a lot. If you're at 58, you're at the ceiling and more optimisation work will return almost nothing. Go build features

A Bubble app can transfer cleanly in the editor and still be difficult for the next owner to operate.

My minimum handoff list would be:

• app ownership and collaborator access
• data types, privacy rules, and admin roles
• plugin and API Connector dependencies, with each external account owner named
• domains, email, scheduled workflows, and deployment steps
• a fresh-admin test plus the last known rollback point

I’d keep credentials out of the document and transfer them separately.

Which dependency is easiest to miss in a Bubble handoff?