Upgrade and lose benefits?

Hello, I’ve been building my app for nearly 2 years (I know…) part time while working etc. I’m currently on the Personal Plan and always planned to upgrade to Growth Plan when ready to launch. Now that time has come, it appears pointless as I will lose the legacy plan and restrict myself to WU. I’m currently using 700k WU in dev without any users!

I do plan to optimise the app, but right now I need to launch and monetise so it really isn’t an option.

Is it worth staying on the Legacy Plan with no restrictions on WU or will the performance be throttled if I have say 50 concurrent users?

I’d quite happily pay the Growth Plan now with no users if it meant I could have unlimited WU or the legacy plan.

I did start to read through the new pricing thread, but there’s just too much to read - can anybody advise if there has been any progress or are we still in the same hole?

Thanks

Stay on the legacy plan - There is 0 reason for you to upgrade. I noticed no speed improvement (live or in editor) - And there aren’t any specific features that require the new WU plans.

So for now, enjoy your legacy plan.

2 Likes

If your app isn’t cash flowing launching on personal legacy is fine. It can handle concurrency to an extent. Just watch your capacity logs and only upgrade if you’re at max capacity a lot.

2 Likes

I would stay on legacy plan and start to optimise your app’s WU appetite :slight_smile:

3 Likes

I’m wondering if you are really ready to launch?
700k WU is really a lot without any users!

5 Likes

Although there’s no direct correlation between WU and capacity use, both are an indication of how heavy/efficient your app is.

The fact you’re hitting 700k WUs with a single User means your app is doing a LOT of work… so there’s a pretty good chance you’ll be hitting capacity and getting throttled if you launch now, once you get more users.

Personally, I’d look at why your WU are so high and work on optimising your app for WU, then switch to the new pricing model as soon as possible, rather than simply delaying the inevitable.

3 Likes

I totally agree I need to look at efficiency, but with the previous plan’s capacity limits, I could have upgraded to Growth Plan and stayed within limits. Now it’s a nightmare.

My app is unique for Bubble - I’m confident there is not another remotely similar app within the same field/sector etc. It’s not your normal CRM/eBay/Uber clone type app. I built this using the limitations that were available (although also pushing those limitations) and now I find myself looking to get out of Bubble at the earliest opportunity when I was anticipating GROWING with Bubble.

I’m actually in a fortunate position that I’ve acheived (modest) funding without even launching on Bubble, but I always hoped Bubble was going to be my proving ground and that I could achieve some monetisation to enable bootstraping rather than already seeking external development without even launching!

I’m absolutely gutted as I’m pretty certain Bubble could use my app as a case study of what can be achieved with Bubble.

In answer to a couple of the responses - yes, I can certainly optimise as there are quite a few workloads that are ‘every 1 sec’ which can be easily changed to ‘every 1 sec’ IF to ensure they are not running unnecessarily . That would certainly decrease the WU required. But it’s frustrating when the goalpoast have been moved so dramatically during building.

Is it worth reaching out to Bubble support or does everybody get the same response?

This is surely the source of your overwhelming WU consumption.

So, in general, polling is bad. There’s no reason, in general, to poll something in web development. The Bubble “do every x seconds” workflow is basically just an implementation of JavaScript’s setInterval(), which allows us to call a function repeatedly after a certain amount of time. This is not for polling some backend state or for repeatedly making some API call. It should be seen as for doing something client side, like manipulating some element in the DOM. For example, imagine an on-screen clock. We might crudely animate the second hand by rotating it once per second.

But we don’t repeatedly ask some external or backend process if it’s done by repeatedly asking it “hey, are you done?” or “hey, has something changed?”. We instead wait for some active notification that something is done or something is changed. That is, web development is event driven.

And now, since Bubble charges WUs for even scheduling a backend workflow (even if that workflow might immediately abort or not fire due to conditions on that workflow), even in situations where we are not exactly polling, but doing something pretty reasonable, we have to rethink where we put our conditions (e.g., move them to the client side).

In terms of features that Bubble has that allow us to avoid polling, there are several that come to mind:

  1. Database trigger events (Database trigger events - Bubble Docs) can be used to run some workflow based on the creation or change to some type of Thing, based on the nature of the change to that Thing.
  2. Searches (the results of “Do a Search for…”) are, in the front end, live queries. If the results of a Search change in a way that would affect the items retrieved by the Search, those search results update. So, for example, if you have an RG showing results of a search for Contacts that belong to some Account in a CRM, if somebody adds a new Contact to that Account, the Contact (if the user has permission to see it) will automagically appear in that list in most cases. (So, we don’t have to poll to find out about such things.)
  3. When working with external systems (remote APIs or other sorts of services), we don’t have to poll them to understand if something is finished or has changed as those external systems can notify us of something important via “webhooks” (the external system can ping our app’s exposed API endpoints, aka “public API workflows”).

Anyway, just some basic ideas there about how you’re going to have to modify what you’re doing.

(Let me also stress that it’s perfectly reasonable to run some completely in-page workflow repeatedly using “do every x seconds”, but the applications for this are quite limited. Honestly, I think that workflow trigger isn’t provided in Bubble because it’s particularly useful, but just that it’s something that JavaScript can do. It’s like, “oh hey we should have setInterval().” Well, OK.)

6 Likes

Thanks for your advice Keith - really appreciated.

I’m not a developer, I took mentoring from an experienced full stack developer and one of the most experienced Bubblers. Although I know 99% of and built most of my own app, some things are just way above my head!

When bubble changed their pricing model he did say to me that we need to make some changes and we’ll hopefully have a session very soon to address this, so I’ll put this to him.

Many thanks

1 Like