I start by apologizing for my poor, translated English. Please don’t judge me for that.
I need to start by saying that even though Bubble has no intention of using “anchoring marketing strategy” with us, the effects caused by the suggestions of the new plans had the same effect as a “anchoring marketing strategy”.
Exemplifying an “anchoring marketing strategy”:
Consider that you pay $100 a month for your electric bill, and the electric company informs you that soon the values ​​will be readjusted, and you conclude that you will start paying $1000 for your electric bill, absurd, correct?
So what would you do? Would it be a good answer to say that you would contact the electric company to try to negotiate this adjustment? What if you could talk to the electric company and immediately get a 50% discount?
Wow, that would alleviate your despair a little, but it’s still too heavy for your budget… so you ask for a bigger discount… Days later, the electric company returns informing that it has become sensitive to your situation, and now will give you an ultra, great, big and super discount of 70%, and instead of $1000, you will only pay a token amount of $300.
In short, the electric company managed to increase your account by OVER 200%, and you still believe you did a good deal. This is the concept of presenting the hurricane (total chaos) chaos for the customer to accept the storm.
Let’s get to the main topic:
I don’t have the best suggestion to solve this whole question, but I always look for the solutions by attacking the problems, because there we find the answers. Thinking in this way, the models initially intended limited the numbers of access and records created in datasabe, the latter being the biggest aggravating factor.
So, we already know that there are these two concerns for the Bubble team - and when I say “big concern”, I imagine it’s really a big concern, because it was these issues that motivated the absurd suggestion of the new plans. What I mean is that I believe that the size of the absurdity of the suggestion is equal to the size of the Bubble team’s concern with this matter.
- Pay for excess rows in the database
Who here hadn’t been wondering how long Bubble would be able to support unlimited records in the database of each application? Every bag has a bottom, and Bubble was handling this issue as if databases had a static size, so the dynamite exploded.
Do I need to count how many times the name Xanu and other services were mentioned here in the forum as a solution to try to alleviate the chaos that the news of the adjustments in the plans caused?
In suggesting the indecent plans, I think Bubble made it clear that he can no longer afford to support the databases, so my suggestion would be to start thinking about adding the database service as a separate new product.
Bubble offers a database service similar to Xanu, and upon purchase, the editor’s database tab unlocks with the contracted plan’s settings.
Of course, clearly and without a doubt it would be immoral if there were plans offering databases by number of lines instead of sizes per gigabyte or terabyte. Forgive me for saying this, but please, selling database lines seemed very amateurish to me, the impression I got is: there is someone very powerful inside Bubble who doesn’t understand Bubble services, and that person is suggesting absurd things and no one is managing to stop this madman.
I think this will be the future of Bubble, breaking down its services: database, front-and, workflow API, etc. And I see this with good eyes, because there would be several services that complete each other, all in one place.
I think in this way, because currently the plans practiced seem to support some services and unbalance others, and we know that no company lives from loss, at the same time no customer cannot be punished for imprudence of the general administration, or for poorly executed plans, or for lack of of vision of the professionals who are paid to lead the company to the new realities of the market and the needs of its customers.
My suggestion to solve the single access problem follows the same suggestion to solve the database problem.