Forum Academy Marketplace Showcase Pricing Features

Monthly Community Update -- September 2021

Hi all,

This is our September community update; you can read August’s update here.

As mentioned and promised in our last update, we’ve been hiring at a rapid pace, and this month was largely focused on onboarding and integrating our new teammates. Also as mentioned, there are real costs to doing this. Our response times to new support requests were significantly worse than in July, in part due to adding two more members of the success team, and training seven other new Bubblers via a brief success team rotation (we have most new hires who join the company spend some time on the success team directly interacting with users). There were some other factors as well: some existing team members had planned vacations this month, and we had some operational issues that resulted in influxes of bug reports.

Previously when we’ve expanded the team, we’ve seen a drop in our overall output temporarily, and then a bounce-back as the new people get up to speed and start contributing. Given our recent round, we’re expecting to see this effect emphasized over the next few months, and we’re looking forward to the dividends when all the great people we’re adding ramp up to their full abilities.

Meanwhile, the no-code movement marches onward. We’re excited to see another college launch a no-code startup bootcamp, and we’re launching a partnership with Founder University as the no-code tool they’ll be training all their founders with. Bubble was recognized as the #1,474th fastest-growing US private company by Inc.

We’d like to welcome all the new hires joining us this month, including:

  • @mariel, who many of you probably already know as one of the leading Bubble experts in the community: she’s joining us full-time to oversee our bootcamps program and help train the trainers.

  • Manasi, Zoe, and Kathleen, who are joining us as engineers. Zoe’s already spent two summers interning with us and we’re excited to have her join full time!

  • Kate, joining us as a product manager.

  • Monica, joining us on the recruiting team.

  • Governess and Clarissa, who are starting as engineering interns for the fall!

If you want to be on this list next month, you can browse our list of open roles! We recently added a new position, Education Associate - Video Producer. We consider previous Bubble experience a plus for any of our open roles. It’s especially value on the success team, which we have openings for in the continental US and western Europe.

Changes we made this month

This was a light month in terms of product changes, but we did add a neat new feature, Magic Links, which provides an alternate login flow for users if you don’t want them to have to memorize their passwords. We also added some in-editor surveys that you might notice, powered by Sprig (formerly known as UserLeap), which we’re using to get real-time feedback to keep us honest about how much improvements we ship actually impact our users’ satisfaction with the product.

On a similar note, we pushed some changes to our Happiness App, which is a Bubble-built app that we link to in every support reply we send: we now make it easy to assign a category when giving negative feedback about a response to help us track patterns over time and continue to raise the bar.

A big internal change we made on the engineering side was that we restructured the way we handle incoming bug reports. Previously we had a team that was full-time on bug reports: we’re now divvying up reports to all the teams based on what part of the product they affect. The reason for the change was that it was getting very difficult to staff the bug-fixing team: operating on it effectively required encyclopedic knowledge of our entire codebase, and we’ve been reliant on a small handful of amazing, long-time team members to make things work. The hope is by distributing bugs to each team, the amount of learning new engineers will need to do to fix bugs will be limited to the code that their team is responsible for, which is a much more scalable way to onboard and train new engineers. Also, sending bugs back to the team that caused them builds a tighter feedback loop, and serves as a natural rate-limiter on development: if we’re pushing too much low-quality code, the team that’s doing the work will have to slow down to fix the bugs it causes, which should overall lead to higher quality across the board. We’re about a week and a half into this transition, so we’re still getting used to operating this way, but we’re all optimistic that this is the right long-term direction.

Some highlights from our blog this month:

  • We added three new instructor spotlights, sharing the amazing stories of our bootcamp instructors Jagdish, Matthew, and Tony.

  • We profiled a Techstars company, Tot Squad, that’s been successful building on Bubble

  • …and added 17 more App of the Day posts featuring all the great things you all are building!

We also did a refresh of all our videos for our input elements. For example, here’s the new videos for using the File Uploader, the Dropdown, and the Date/Time Picker elements!

This month in numbers

  • Total number of conversations via bug reports or [email protected]: 7,499 (up 17.2%).

  • New conversations via bug reports or [email protected]: 6,983 (up 14%).

  • Average first response time to messages: 1h 59m during business hours (up 41.1%)

  • Average response time to messages: 2h 31m during business hours (up 43.6%)

  • Time to resolve bug reports escalated to the engineering team: the average lifespan of open bugs and bugs resolved in the last month is 6.1 days (down from 6.2)

Things on our minds

This month has been a little rough on the operational side of things. Yesterday we had extended issues due to the major Amazon Web Services outage, and we weren’t able to route around the broken availability zone effectively due to some issues with our infrastructure and processes. We’re still confident that in the event of a major AZ or regional outage we’d be able to get back online eventually, but there’s a lot of work we’d need to do to make it a fast, easy process instead of a long, laborious one. We also had some unrelated issues with a database system that’s under too much load, and there were two major incidents where we rolled out code that introduced bugs in a number of production applications, both of which took us longer to resolve than we would have hoped for.

We view getting to a better place on these kinds of incidents largely as a staffing challenge: the aggressive engineering hiring we’re doing should pay off in terms of the ability to devote resources to long-term remediation and process improvements, but currently we’re stretched thin and have a lot of new engineers who are still learning our systems. That said, we’re still tactically trying to learn from each thing that went wrong and implement any lightweight improvements that we can glean from it.

What we’re currently working on

  • Performance: we’re still doing a planning, metrics, and user-research deep dive. It’s looking like the biggest user pain points are query execution speed, followed by page load speed. This isn’t a huge surprise given the feedback we’ve been getting from you all, but performance is a pretty broad area and it’s valuable to confirm we’re actually focusing on the things that will have the biggest bang for their buck.

  • Version-control reliability: the good news is we built the last round of fixes we were planning to do, which covers all of the known-broken things with our algorithm. The bad news is that this round of fixes aren’t quite working as intended yet, so we still have some work to do to debug and harden them.

  • Migrating code to Typescript: the self-contained chunk of this we wanted to do over the summer is mostly wrapped up, though not deployed yet. We’re also doing a larger project to get the rest of our codebase off of Coffee-Script and onto vanilla Javascript, which is the first step in getting our entire codebase onto Typescript.

  • SelectPDF replacement: still on ice for now.

  • New responsive design engine: the engine itself is feature complete. We’re still doing a bit more work on repeating groups, and on the code to allow page-by-page migration of apps from the old engine to the new engine. In the meanwhile, we’ve been testing it with users, and making some small improvements to make it easier to learn the new functionality, as well as building educational materials on the new system.

  • Redesign of our editor: we’re pushing hard to get to a private alpha with users. The main blocker right now is that there’s some performance regressions relative to the current editor, which we’re debugging and fixing.

  • Bootcamps: we’re doing preparation work for a new 1-week intensive fundamentals bootcamp, and hoping to launch in September.

  • Immerse: we’re excited to be preparing for our next cohort! The program was just featured in Forbes

As always, have a fantastic month, and thank you for all your support!

– Josh and Emmanuel


Great job so far guys, keep up the hard work

Thanks, @josh. Stoked about the responsive design engine and editor redesigns!

1 Like

@josh I know you’ve been asked this a million times, but with this so seemingly close to being available, when do you expect that to actually be?

I’m currently dealing with a responsive issue that cannot be ‘hacked’ because of the current responsive engine approach and I’m dying to use the new engine.

Thanks for the updates!


@alex.pethick I’m going to continue avoiding this question. I talked to the team about it a week ago, and they were like “pleassssssse don’t commit us to something, we want to get this right”, which I support. We do have an aggressive internal goal for getting this out (although the first step will be to give it to template creators so they can start updating templates, before we roll out more broadly). I know it helps the everyone plan their own app developments when we give expected ETAs, but frankly our track record for being in the right ballpark has been extremely bad (see: editor redesign), and I think an inaccurate ETA is more harmful than not giving an estimate at all, so I’d rather wait until we’re reliably hitting estimates to start sharing them publicly in these threads. What I will say is that this will almost certainly not be broadly available in Sept.



As the selectPDF replacement is still on hold, which probably frustrates a lot of people and you’ve just got an awesome funding round maybe it is a good idea to contact some plugin builders to help you integrate their work natively in Bubble (,as there is funding to do so).

Two examples who are in the top of my head:

  • There are quite a few good calendar plugins, but the native Bubble one lacks behind on features.
  • The current Stripe V3 plugin makes use of the Payment Intent API, but doesn’t include a lot of parameters, which limits the functionality of the plugin.

With making these plugins native, you will probably also have the opportunity to do more than the plugin builders as you are at the code base of Bubble.

It would be awesome if you could let us know what you think!


@klaas.vanhoeck1 And anyone who would be interested in the SelectPDF replacement plugin, and in advance I apologize for the slight hijack of the thread, but last week I released in the PDF Conjurer plugin the ability to run it in backend workflows, so now the plugin is very complete and covers many more use cases, and it’s free to use.

It is not a direct replacement to SelectPDF, since SelectPDF relies on visiting a page and transforming it into PDF, but given PDF Conjurer’s flexibility and power, there is a lot of stuff that can be created in the backend by the ones who need it, so it’s definitely a tool worth looking into.

On getting plugin makers to work on natively integrated stuff: That sounds good!
I mean, we already have community members as trainers on bootcamps and as freelancers and agencies being recommended, this third step makes sense.
However, it would be much simpler to get more and better tools in the plugin editor. We would be able to do even more than what’s already possible.


In all my code ignorance, I remain curious: why this move? What are the benefits? I imagine the benefits are internal to the Bubble team, but I’m still curious.

Hi @josh - As a UI/UX nerd, I would love to be on the alpha team for the redesign testing.

From a previous update …

1 Like

would be great if there is a beta registration for users who will be fine with bugs but want to start earlier.

1 Like

That’s an interesting idea, thanks for suggesting it. That said, having someone do work on built-in plugins requires more oversight and training than using our public plugin editor; the internal APIs we use are significantly messier than the external ones, so essentially it comes down to onboarding, training, and managing another engineer. We’re trying to focus on doing fewer, better engineering projects right now to get more wins, so we want to be very cautious about kicking off new initiatives

Two things:

  • We want to be off of coffee-script because it’s increasingly becoming a liability. It was a popular language when we started Bubble in 2012, but for various reasons the ecosystem moved away from it, and it’s now a bit of an evolutionary dead end. It makes it harder to recruit engineers since most people aren’t excited about learning it, and adds overhead to training engineers.
  • Typescript on the other hand has a ton of momentum behind it, and it offers some significant advantages in terms of the ability to declare static types. Static type declarations catch a lot of bugs in code that otherwise would have to be caught by testing. It typically boosts engineering productivity and leads to higher quality code.

I support this! Thanks @josh for the update

1 Like

Will it break every template out there when rolled out or will you follow the same ‘evolutionary’ approach like with plugins? (API 0, API 1, API 2)

Old templates will still work, but we’re going to strongly encourage template authors to convert them to the new system by featuring new system templates much more prominently in searches (since we want new users to Bubble who buy a template to end up on the new system)


@josh , we’d love to be part of the user research on performance as it’s been a big issue for us. If you are still looking for people to talk to please feel free to reach out.