Bubble plugins that have no code equivalent
The plugins that hurt are the ones nobody can name a replacement for. Here is how to find yours before it becomes a discovery in week six.
Lucian Lutas
Most Bubble plugins are not a migration problem. They are a wrapper around something that exists independently: Stripe, SendGrid, Google Maps, an SMS gateway. The plugin is a convenience layer over an API you can call directly, and replacing it is a known quantity.
The plugins that hurt are the ones that are not wrappers. Something a developer built, that does a real piece of work, that has no equivalent you can buy, and that your app depends on in a way nobody has written down.
This is how to tell the two apart before you commit to anything, because the difference between them is most of the variance in a migration quote.
Sort yours into three piles
Open the plugins tab and go one at a time. Do not skip the ones you think are unused, because "I think it is unused" and "it is unused" are separated by exactly one search.
pile one: wrappers
- The plugin has a vendor behind it that you already have an account with
- Removing it would mean calling that vendor's API directly
- The plugin's settings are mostly an API key
pile two: UI components
- It draws something: a calendar, a chart, a rich text editor, a signature pad
- It holds no state that outlives the page
- There is a mature open-source equivalent in the React ecosystem
pile three: the expensive ones
- It does work rather than drawing something
- You cannot name what it would be replaced by
- The vendor is one person, or the plugin has not been updated in years
- It touches money, identity, or a regulatory requirement
Pile one is a line item. Pile two is a week of work across the whole app and usually an improvement, because the React equivalents are generally better maintained than the Bubble wrapper around them. Pile three is where quotes go wrong.
Why pile three is expensive
Not because the code is hard. Because the specification does not exist.
A plugin that does real work encodes decisions: what happens on a partial failure, what it does with a malformed input, which edge case it silently tolerates. None of that is written down. Some of it is not even visible in the plugin's settings. It is behaviour that your users have been relying on, sometimes without anyone noticing that they were.
Rebuilding it means first discovering what it does, and discovery is not something anyone can price by looking at your plugin list. This is the honest reason nobody can quote your migration properly without opening the app, and anyone who gives you a fixed number sight-unseen is either padding heavily or about to have a difficult conversation with you later.
The specific ones that come up repeatedly: signature capture with any legal weight attached to it, calendar and scheduling components with recurrence rules, anything doing document generation, and niche regional payment or identity providers. Recurrence rules in particular are a genuine trap. They look like a small feature and they are a well-known source of subtle bugs in every language and framework that has ever tried to implement them.
The audit that costs you nothing
For each plugin in piles two and three, answer four questions in writing.
Where is it used? Search the app, do not rely on memory. A plugin used in one place and a plugin used in forty are different projects even if the plugin is identical.
What happens if it fails right now? If you do not know, that is the answer, and it is worth knowing before you rebuild it rather than after.
Who last touched it? A plugin whose author has stopped publishing updates is a liability whether or not you migrate. This is a genuine reason to leave that has nothing to do with cost: you are depending on a component with no maintainer, inside a platform where you cannot fork it.
What is the smallest thing that would satisfy the users? Frequently the answer is much less than the plugin does. Plugins are built to be general. Yours is one app, and rebuilding the twenty per cent you use is a fraction of rebuilding the plugin.
That last question is where the money is. It reframes "rebuild this plugin" into "rebuild what we actually use", and those are not the same project.
What we do with pile three
Three options, in the order we usually recommend them.
Leave it on Bubble for now. Incremental migration means you do not have to solve everything before you start. A workflow that depends on an awkward plugin can stay where it is while the rest of the app moves, and it can be the last thing you deal with, by which point you will understand your own system considerably better. This is the default and it surprises people.
Replace it with a service. Sometimes the reason there is no code equivalent is that the correct answer is not code. Signature capture with legal weight, identity verification, and document generation are all things you can buy, usually for less than a week of development and with someone else carrying the compliance question.
Rebuild it properly. When it is genuinely core to what your product does, and when the answer to "what is the smallest thing" is still substantial. This is the option that costs real money, and it should be a deliberate decision made with a number in front of you, not a discovery made in week six.
The number nobody can give you
There is no plugin-count-to-price formula and we will not pretend to have one. An app with fifteen plugins that are all pile one is straightforward. An app with three plugins where one is a custom scheduling engine is not, and it will cost more.
What we can say is that this analysis is not the expensive part. Doing it takes an afternoon of your time and it changes the shape of every quote you receive afterwards, including from people who are not us. If you would rather have it done properly, with the app open, it is one of the five things the audit produces. If you are not yet sure a migration is worth considering at all, start with when to leave Bubble, and when not to.