A few top-of-mind thoughts here. I’m not out too assume to know what everyone is thinking, just to try to clarify different perspectives.
Most active Bubble users of today probably found this platform in one of two scenarios: looking to cut costs on development, or looking to not have do rely on developers altogether. Both scenarios are likely start-ups on their own, or within an organization. The point I’m making is this: the expectancy of cost reduction might be artificially high. Said in other words: Bubble’s clients are on the extreme side of price sensitivity. I’m not criticizing here: I’m one of them.
Personally, I quit my job to work on a my start-up. USD 10 per month is a serious commitment for me, as crazy as it may sound, as it is all coming out of my savings. Not because USD10 is a lot, but because these costs never come alone. It’s not 10USD per month, but 15x10 USD per month going in different directions. In my old job, however, a 5 or 10 dollar cost per month would mean absolutely nothing. Perspective matters.
Obviously, this is not the fault of the plugin developers. They have every right to expect a ROI on the hours they put in, and can’t be blamed for Bubble attracting mostly low-budget startups at this point. I agree with @tom1’s point though: plugin developers are the future Bubble big earners. As early adopters, you’re basically setting up a monopoly on plugging Bubble into the most popular API’s – a monopoly that can have a huge value as Bubble grows. We don’t know that for sure – but we’ve all made big bets committing to Bubble. We can’t demand that kind of patience from you, but we can argue that it would both be an altruistic service towards the community, and, in your self-interest, plugins are already a cornerstone of Bubble, and making them more accessible would stimulate growth of the whole platform that you can benefit from in the future.
I can say one thing for sure: at bunch of times, I’ve looked at a plugin, mentally calculated the running costs and said: “nah”. It might be a feature I would want to include, but I simply can’t take the chance of running costs increasing too much. Again: this is not criticism towards developers, it’s simply stating a fact: in 90% of cases, I simply don’t buy it.
This is getting long, but another important point for me, and I suspect for many: there’s a huge difference between costs while in development, and costs while LIVE. The former can ruin a company, the latter is simply cost of doing business. My app has been in development close to a year. If we had a way to separate plugins used only in development, from those that are live, I would see it in a completely different light. I’d implement the plugins, test them thoroughly, and gladly pay for them in the live version. If my app is not able to pay for those costs after going live, then frankly, it’s not a good business. During development though, I’m eating noodles for breakfast, lunch and dinner to make my budget last.
Another way to balance costs between young and established companies is in tiers: scaling plugin price along with traffic, just like Bubble’s main pricing.
Developers, I understand your concerns. Especially when it comes hours spent on support etc. after release. Lowering the price would attract more users, resulting in even more support hours. I’m not blind to that cycle.
I simply agree that with today’s model, Bubble’s early adopters are taking the blow, and I know for a fact that personally, I’m not even considering plugins that set me back 120 dollars a year. Decisions like that would kill my company.
I’d implement the plugins, test them thoroughly, and gladly pay for them in the live version. If my app is not able to pay for those costs after going live, then frankly, it’s not a good business. During development though, I’m eating noodles for breakfast, lunch and dinner to make my budget last.
You also have to remember that as soon as you move live your app wont necessarily start to make money form day one, it takes time to find / attract paying customers. But I know what you mean.
Other than cost of subscriptions, the other major concern is unsupported plugins once the developer decides to move on. You become reliant on the developers again, not having to do this is one of the main reasons we were attracted to Bubble in the first place.
The plugin ecosystem is not set up to handle this automatically at the moment, as I understand it?
If other users and plugin builders agree, we could suggest this to the Bubble team. I’d welcome other views and more input before taking that step though.
With costs of the plugins aside - What if the plugin developer decides to leave Bubble? Offers no technical support or doesn’t update the plugin? Where would that leave the Bubble customer who relies so heavily on these plugins in their live app with Bubble?
We currently use a range of web based apps from web hosting with GoDaddy to finance/accounting software with KashFlow and a ticket support system with LAdesk… all have their own plugins for stripe, paypal, social media, google, etc, etc… I couldn’t imagine a case where we’ve had some difficulty with a plugin and the platform provider has responded by saying, “Sorry, you will need to get in contact with the plugin developer”, or “Sorry, the plugin is no longer being updated as the developer has gone AWOL”.
This is all well and good, and of course plugin developers should be rewarded for their work accordingly - but where does that leave the customer who has come to Bubble to put their trust in, and to host their website/app solely with Bubble.
I can see Bubble becoming very popular with small-medium sized businesses looking to develop their own website/apps over time. Even as popular as website builders with 123-reg and GoDaddy, but not in a case where plugins are uploaded like the App Store - some work, some don’t, no response from the developer, etc, etc…
If this takes off and Bubble suddenly explodes with new plugin developers and many lovely new plugins, they are also putting a hell of a lot of trust in those developers with their reputation.
There are a ton of considerations when it comes to plugin building. As we’ve seen from other plugin developers, being experienced in JavaScript still requires a greater level of patience with the Bubble plugin development suite. Some of the hard thinking actually comes around user experience of that plugin too. If you’re interested in getting a glimpse and the basics into plugin development, take a look at this course:
It’s not perfect, but it has inspired a handful of developers who reached out in Sessions with us!
Took my time to prepare the list of 25 most successful premium plugins (31/01/2018).
Why only 25?
Because only 25 plugins were actually bought by at least 1 person and are used in at least 1 app… So I just took them all
So here they go, sorted by the number of applications (sorry, I named the column “users” while it’s “Applications” or “Uses” - without “r”)
Now, lets see per creator - how many plugins, how many uses and monthly income:
OK… scary…
Advanced Ziggeo Plugin by Bubblify is the most expensive plugin in the Marketplace - 14USD.
87 users decided to pay for some plugins? The most successful free plugins have few thousands applications. Are the prices too high? Are the paid plugins not interesting with what they do/offer? Are actually the Bubble users just using free version and free plugins, absolutely not being interested in anything paid? We never know… But c’mon - 87 TOTAL is just 1% of ONE free plugin! Sure, plenty of these apps are just prototypes, abandoned, etc. Stil…
Sum of price is interesting - what I would pay, if I wanted to use all plugins from this developer. So for example: 9 plugins from Bubblewits would cost me 64$ per month, while 12 from Plugbubble “only” 59$ per month!
Sum of per month - what developer is touching. No, wait - there is Bubble commission… Anyway - 5 developers, offering 25 plugins altogether, having them used in 87 applications total are getting 546USD per month, minus Bubble part.
I really hope @emmanuel and the Team have the PLAN.
The issue I think Bubble has is what most disruptive start-ups face, and I have done a few, successes and failures. There is a lesson here that all of us can learn from.
To be disruptive you need to create your own paradigm (the law of doing things) but the risk is there is no roadmap. With no map to follow you are literally walking in the dark, but as you get traction you start to be pulled towards the light, in this case established market forces. But, you really need to stay in the dark and light your own path so others can follow.
The friction we can observe here is that between those who came here based on the premise that we no longer need to rely on traditional development (following Bubbles disruptive path) and traditional market forces shining like a beacon in the dark (established ways of supporting platform growth like WordPress and its myriad of supported and unsupported plugins).
It appears the Bubble team have a decision to make and whether they stay with the initial premise of building without code, or take a path along side those that already exists. It would be a shame if Bubble decide to move into the hybrid model, but I guess at the end of the day we can all be altruistic when it comes to our intentions but its money on the table that matters!
My own personal view is that I would rather own the plugin than have to rely on a third party for support which may or may not occur. Try explaining to a VC that you have a product roadmap that relies on a multitude of developer plugins for your success and see how far you get! However, it does depend on your intentions if you are using bubble to test an idea then that’s fine. Once you get funding you can drop Bubble and move to in house coding.
I would like to stay with Bubble! I have even consider moving my core SaaS business from its current Python platform to Bubble, but until the issue discussed here are addressed I am more than a little nervous about making that move.
Thanks for putting these all together. However, the numbers that you see on the plugin installs are not really accurate. So when someone installs the plugin and removes it before their next billing cycle on Bubble, they don’t get charged (we don’t get paid) but the count of plugin installs doesn’t change.
to be honest I’m not 100% sure but as far as I remember it’s per app.
It’s not developer-specific setting, so this question is more for @Bubble
Thanks!
Levon
Some of the questions after reading through the discussion:
Does Bubble have a policy for when a plugin provider moves on or decides not support to update a plugin any more? (For example, do we then have access to the plugin code)
Is there an expected SLA to be part of the plugin supplier network? What is that SLA? What if that SLA is not met? As a customer, how much can we rely on an SLA enforcement?
What is the purpose of the third party plugin network: Alleviate Bubbles need to build new features? Give Bubblers the opportunity to extend their apps? Or transition towards traditional development in the Bubble universe? How much will we need to consider traditional development for our apps in the future?
How do non developers who came here to build without code feel about the growing reliance on third party plugins for new features?
Having already invested about 6 months of my time in learning and created an app, the whole reliance on plugins for extended features is concerning for many of the above reasons! If I now need to start learning JavaScript for the future I would rather know now than be left with a looming disaster when I have customers paying me money.
I believe those questions are extremely good and require a proper answer on their own. They are entitled to a new topic as this thread was open with pricing in mind.
Saying this because it seems this topic is not getting love from @Bubble team at the moment and your questions maybe would get attention if they were not buried within this thread.
Hey guys, just so you know, we are following this thread There’s some very helpful ideas and thoughts in here.
I’ll give a bit of perspective on how we’re thinking about pricing models right now (and I’ll reply to the new thread that @StevenM started in a minute)
Basically, where our head is: we’re still rolling paid plugins out, and think it’s too early to tell whether or not the model works, in terms of creating a healthy ecosystem that’s good for both plugin developers and bubble users. Paid plugin development is still in invite-only beta (and thank you so much to the early adopters who’ve put up with the bugs and issues!), and we haven’t launched server-side action plugins yet, which is a big piece of the overall picture.
We are actively working on finalizing the plugin marketplace and opening it up to the public, and until we launch it and see it in action for a couple months, we’re unlikely to make big changes to the way things work in terms of subscriptions. That said, down the line, we’re open to adding additional options if they still seem like good ideas (such as paying for a perpetual license upfront, or experimenting with different forms of free trials like @petter suggested above, or allowing pricing based on usage).
We think the subscription model is likely to work out well for both buyers and sellers, for reasons that several of you already pointed out on this thread:
Many Bubble users are just getting started with their companies, and expect their future income to be higher than their current income. In that situation, it’s better to push your costs down the road as much as possible instead of paying upfront
Having an ongoing subscription revenue incentives plugin developers to keep supporting their plugins, because if users are unhappy, they can switch to a different solution, so it keeps plugin user and plugin developer incentives aligned long-term
From a plugin seller point of view, subscriptions give you a predictable ongoing revenue stream that gradually grows over time
That said, we definitely hear the concerns being raised on this thread. From a buyer perspective, I definitely understand how it can be daunting to add to your monthly bill. And from a seller perspective, I understand that the math isn’t working out right now, though I hope you guys see it as a long-term investment in the growth of the platform that essentially gives you some equity in Bubble. We’ll definitely stay close to this and change things as necessary to make sure both buyers and sellers stay happy.
I’d also like to chime in to share two thoughts / perspectives that I think are missing from this discussion:
My biggest concern with plugins is that Bubble won’t build core functionality into their product when a plugin already offers this functionality. For example, Toolbox offers a “Run Javascript” feature that, in my opinion, should be built into Bubble natively. Toolbox happens to be free, which works well, but if it were a paid plugin I’d be disappointed if Bubble chose not to build this feature into Bubble. I suspect we’ll run into more issues like this in the future and am curious to hear how Bubble plans to address them.
I don’t think we should compare the cost of plugins to the cost of Bubble, but instead to the cost of writing something in custom code ourselves because that’s the real alternative. Accordingly, I’m happy to pay for plugins that provide valuable additions to our product and are production-grade in terms of quality and reliability. In fact, I hope plugin makers can charge more (and be more financially successful) so that more people choose to make plugins.
That’s why I think it needs to get discussed. It’s not okay to me if a plugin holds users ransom by building a core feature and then charging, say, an exorbitant amount of money for it.
On the flip side, I completely agree, it’s not good for developers if Bubble incorporates their apps into their core without buying out those companies/plugins.
There are plenty of ways for Bubble to manage this, and I suspect they will want to handle it on a case by case basis. That said, it’d be helpful if they could lay out their philosophy and some good rules of thumb so that everyone knows what to expect.
As a buyer there is the option that we get someone to build a plugin for us, where we own the plugin. I assume this option is available to us?
It could also be a Bubblers crowdfunding option where a bunch of us come together to have an essential feature built for us that we feel should be core functionality. This might address @sridharan.s concerns about core features being over priced or not up to scratch?
I also think @josh has a point about us being the moderator- at the end of the day if we don’t want to pay or bound to a plugin we don’t buy it. If an alternative option is available where we can avoid another monthly fee then we buy that one.
I think a lot of us non code Bubblers (Entrepreneur types) came here to avoid the dev rollercoaster and much of the pain it can bring, so we are worried we are heading back down that road. In many respects it’s a little more risky because at least with an internal dev team we have tighter contractual control over what is being built and how it should be fixed.
but as far as I remember it’s per app.