Hi Lizzie, to be very clear, we do not have any plans to further change the way WU is calculated right now. After we first announced WU, we made some substantial adjustments based on initial community feedback, and before making any further changes, we would like to see how WU works in practice for users who are scaling up on our new plans. We expect it to take at least 6 - 9 months before we have a real perspective, because apps on the new plans are generally either new as of May, or switched because they were not consuming much WU. As of our end-of-May billing cycle, only 1.5% of apps on the new plans had any WU-related overages at all, so we don’t view May as representative of what things will be like longer-term.
What we do plan to do:
- Invest in more efficient ways to manipulate large amounts of data. This was on our radar as an important problem pre-WU, and a lot of the community feedback around WU was that this might become too expensive in the new system. We are targeting Q3 for releasing features here, and are currently doing research and technical exploration to figure out exactly what this should look like.
- Continue to invest in our DDoS mitigation workflows, both in terms of preventing attacks in the first place, and making it seamless for customers to have their charges waived if there is an attack
- Invest in better tooling for debugging WU usage. The main thing we are working towards here is making the pie chart that shows WU usage more granular, both in terms of ability to drill into things, and in terms of resolution (going from an hour to a minute). We are aiming for end of month though it may slip into July.
See my reply to Lizzie above for our top WU-related priorities. There were a ton of other great ideas from the community, and we’ve captured all of them, but we are holding off on building until we see what the biggest problems are in practice. Our experience is that problems anticipated in advance of using a new system often turn out to be minor in practice, and the biggest pain points are often things no one thought of. It is still very early days for WU, and we would like to see the trajectory of apps built in the new system that start acquiring users and scaling to understand what’s working and where the problems are.
As mentioned above, don’t count on any changes, at least in the near term. The way we’re thinking about our overall price competitiveness is:
- We want to charge a substantial platform fee for using Bubble, higher than was charged on the legacy pricing plans. We feel this is justified by the cost-savings relative to building out an engineering team, and necessary for us to keep investing in the platform the way we want to (ie, we need to keep growing our own engineering team).
- To keep Bubble accessible, we don’t want that platform fee to land on all our customers equally, which is why we did not just hike the rates of base plans. Rather, we want to distribute the platform fee based on usage, so that it is minimal for people starting out, and scales as apps increase in usage. We’ve done this by charging based on workload with a substantive markup.
- That said, to your point, we can’t justify an indefinitely-large platform fee as customers continue to scale up: eventually it does become cheaper to build out your own engineering team. We are addressing this with volume discounts for WU units. Some of those discounts can be seen by looking at the pricing for our various WU tiers; we plan to offer further discounts at the Custom plan level, slowly converging towards costs as customers approach true enterprise scale.
Thanks for the interest! Please DM @nick.carroll
We have made a lot of progress on SOC2. I can’t announce the timeline yet, but this is in “coming soon” territory, not “we have a lot of work to do on our end” territory.
It is not a false alarm. Those issues have been caused by our database being under real stress, causing performance impact, and throttling user apps defensively to enable it to recover. We view this as a genuine outage, and are very sorry for the impact it has had on your business. The only reason we haven’t been louder in our communication about it is that the overall customer impact (# of apps and severity of outage) has generally been lower than site-wide outages we have experienced in the past. But we are taking it extremely seriously and our Platform team has been hard at work mitigating the issue. Since I posted the community update, we deployed several fixes, and we are optimistic that we’ve addressed the major root causes.
On our radar! No in-progress work streams I can announce yet, but we will be following up with early SSO customers to dig into this further.
We don’t think the issues are because it is in-browser / javascript: the challenges are more because a lot of our javascript is out-of-date or written inefficiently. We are making steady progress improving this, though! Separately, we’ve considered the idea of wrapping the editor in an Electron app or something similar, but that wouldn’t be a magic bullet to fix performance, and we have this idea low on our list because we think the effort vs the payoff wouldn’t be that great relative to other things we could work on.