[New Thread] More context on our changes to pricing - FAQs answered

Something I want to share.

Our company received an acquisition offer of $10m recently. We have a great product (built with Bubble) that is in high demand and it was a large CRM looking to buy us up as feature to add to their platform.

We started talking about tech stack, and the acquirer backed out a week later. They said they weren’t interested in buying a product that was locked into a provider like Bubble, too much platform risk.

Heartbreaking.

We always knew that a sale for our tech would be difficult if we were built on Bubble, but we consoled ourselves that the speed and cost effectiveness of Bubble development made up for this lack of IP value.

“We will out build them,” we thought, “We will prove them wrong about Bubble!”

Boy, do we feel really dumb right now.

It’s clear that Bubble is looking at the apparent disparity of how expensive/hard they think it is to develop in code, and they want to be able to charge something that reflects some of that value they think Bubble is providing in that regard. The want us to “share our pies” so to speak, eh @keith?

Here’s the problem: The value of an app developed on Bubble is NOT the equivalent of an app developed with traditional code. NOT EVEN CLOSE. Even if the functionality is identical.

For me and my company, the difference in value ended up being $10 MILLION DOLLARS.

Your platform lock-in negates a massive portion of the value you think you’re providing. That’s ok, as long as your pricing reflects that, but this new pricing does not reflect that.

Why the hell would I develop a product on Bubble when…

A. It is worth a fraction at exit of what it would otherwise be worth if built in code?

B. It costs 1000x what it costs to run/host a product built in code (not including development cost)?

C. It has a substantially less predictable cost structure than regular code?

“Oh but AJ, you’re saving $100,000s on the actual development of the code.”

Have you heard of CHATGPT?

Have your heard of FLUTTERFLOW?

Have you heard or DRAFTBIT?

Have you heard of NOODL?

These are just a few of many no-code tools for generating actual standalone codebases. Might not have been viable a few years ago, but THE MARKET HAS CHANGED. This new proposed pricing shows a shockingly level of “head in the sand” to that fact.

Speaking of “head in the sand” mine has been in the sand about the absolutely ludicrous idea that it was ok to trust Bubble with complete control of my application when I’m building a serious business. That the trade off of full control for (what is now a slight) easier time of building, was an acceptable one.

This fiasco has completely shaken me of this idea. I stood by Bubble through the last pricing disaster, thinking they learned their lesson, but it is clear that they have not.

No matter what kind of changes or backpedaling we see next week, I cannot wait to transition off this platform.

Don’t get me wrong, I’m stuck here for right now. And tbh I may end up having to use Bubble as frontend for a while until we are able to completely rebuild it with react native or flutter (via the above options), but there is no doubt in my mind that we will be leaving, hopefully before the end of the 18 month window.

We made a $10m mistake building here in the first place. I won’t allow that number to continue to grow with ridiculous pricing layered on top. I’m simply not interested in paying a premium to be at a massive disadvantage relative to any other development path.

59 Likes