Hi all,
This is our October community update; you can read September’s update here.
Hiring and building the team was our main focus this month, as it was last month. We’ve been interviewing for roles across all parts of the company, both for immediate hiring needs as well as college students who would join us for internships or after graduation.
We’re definitely feeling the strain of interviewing potential hires and training everyone we’ve already brought on board. Our response times to user requests took a hit this month, and it wasn’t a great month in terms of uptime or shipping features. That said, I think we’re doing a good job setting the foundations for long term success: we’re really happy about everyone who has joined the team, and so far we’ve managed to avoid many of the organizational and cultural growing pains that a lot of companies face when they staff up.
In particular, we’re thrilled to welcome Michael, Ikenna, and Rachel to the Success team, Rohan to the Product Management team, and Aryan as a Growth intern: they all started in September.
If you’re interested in joining us, here’s a list of our open roles. In particular, we just opened a Bubble developer role, because we now have enough Bubble development work on our homepage and our various internal apps that it justifies a full-time position. We value previous Bubble experience for all our openings, but that job in particular we’d like to fill with someone experienced from our community. Likewise, our Customer Success role is especially good for experienced Bubble developers who like teaching and helping others. We’re making a push to extend the geographic reach of the customer success team: on our jobs page, we have listings for New York and Western Europe, but we’re in the process of expanding that, so if you live outside those geographies but want to join us, please do apply (submit your resume to the posting you live closest to).
Changes we made this month
This was a relatively quiet month in terms of product updates, but a few things to call out:
-
We opened applications for our next cohort of Immerse. Application deadline is October 4th at midnight ET, so there’s still a few days left if you’re interested! We also got another nice article about the program in the press.
-
Our Success team launched version 4 of its internal documentation tool. We think this is the version that will stick: it’s more robust and enables us to access shared knowledge faster, which should feed into faster response times.
-
We added several new videos, including documentation of our repeating group element, search box element, and user is logged in event.
-
On our blog, we published 11 new interviews with our users, including apps of the day and bootcamp instructor profiles
This month in numbers
-
Total number of conversations via bug reports or support@bubble.io: 7,026 (down 8.3%).
-
New conversations via bug reports or support@bubble.io: 6,564 (down 8%).
-
Average first response time to messages: 3h 30m during business hours (up 77.5%)
-
Average response time to messages: 3h 43m during business hours (up 48.7%)
-
Time to resolve bug reports escalated to the engineering team: the average lifespan of open bugs and bugs resolved in the last month is 8.7 days (up from 6.1)
Things on our minds
We had a number of internal conversations about support coverage this month, prompted by a partial outage that impacted a number of user apps and that we didn’t become aware of for over 12 hours. We’ve always planned to move towards 24 / 7 support coverage, because we have users running mission-critical businesses in all timezones and know how painful it is when they can’t get support from us on short notice in an emergency. This incident reinforced our sense of urgency around getting there, and we’re working on what a staffing model for 24 / 7 support would look like. Following our fundraising round, we have the budget to build the necessary team, so our main bottleneck is hiring and training (see above!) Our current thinking is that we’ll likely proceed in phases, incrementally expanding the hours we provide coverage as the team grows, with the goal of shrinking the uncovered gaps until we’ve achieved round-the-clock coverage.
Another big topic of internal conversation this month was the editor redesign project we’ve been working on. As those of you who’ve been following these updates are probably aware, the timeline for completing this project has stretched considerably, to say the least. The project started as a simple re-skin of the editor to make the appearance more modern; it expanded in scope to include a significant technical overhaul of how the editor is built behind the scenes, as well as a number of UX modifications. In essence, it became almost a complete rebuild of the editor, which we’ve been working on in parallel to maintaining the current editor.
Rebuilding the editor has been enormously challenging, because there’s a lot of hidden complexity in how the current editor is constructed that ended up having to be dealt with to make sure the new editor had feature parity with the current editor. To make matters worse, we’ve continued to add features onto the current editor, such as the responsive design overhaul that’s nearing the finish line, meaning that working on the new editor became somewhat of a race to make progress while keeping up with the latest additions. Adding to that, as we built the new design and started using it internally, we realized there were actually a lot of things we didn’t like about it, introducing a lot of additional work to improve its shortcomings, since we didn’t want to release something that was inferior to the design we were replacing. Finally, any technical project of that scale introduces tons of new bugs, and QA’ing a product as broad and complicated as the Bubble editor is a major challenge in itself. As a result, our timeline estimates for the release date kept on pushing further and further back.
We’re now in agreement as a team that it was a mistake to build this project as a side-by-side replacement instead of making the changes incrementally on top of the existing editor. I feel a little silly writing this, because it’s basically a maxim of software development that complete system re-writes are almost always a terrible idea. Looking back on how we got here, it was a combination of gradual scope and ambition increases, followed by a “well, this is taking longer than we hoped, but we’ve invested so much now that it’ll be easier to just push through to the end” mentality, well after the point that we realized that we should have built it incrementally from the beginning.
There’s never a great moment to adjust course in a situation like this, but after it became obvious we wouldn’t get to our planned alpha by the end of the summer, we started asking ourselves what the best path forward was. We spent the last month doing a series of technical pushes to see how fast we could make progress against some of the biggest blockers to the alpha release, as well as brainstorming alternate approaches.
The key tipping point for us was realizing that we had built a great team around the project but that none of their work was seeing the light of day, while the current editor that the whole community is on hasn’t evolved much over the past two years. We also realized that a lot of the technical work we had done in the new editor to make the code more maintainable could actually be moved back into the current editor in a piece-wise fashion, and that we were more attached to that technical work than we were to many of the design changes in the new editor.
As a result, we decided this week to shift all our development efforts back onto the current editor, using the redesigned editor as essentially a parts bin of components that we can draw on to improve the current editor’s technical architecture, make some of its UI interactions more consistent, and upgrade a few key components. Rather than one big project spanning months or years, we plan to have the team do lots of small projects, each targeting a pain point or friction in the current editor, and pull code from the redesigned editor as appropriate.
One consequence of this path is that we’re probably going to keep the current editor’s look and feel for an extended period of time, because we’re only gradually going to upgrade the technical underpinnings that would make it easy to quickly and safely adjust the appearance without risking lots of bugs and inconsistencies. While we aren’t in love with the current editor’s design, ultimately we feel that making the editor prettier in the short term is less important than continually improving the editor’s UX and feature set. Our goal is to eventually get the editor to a place technically where changing its overall style is easy and painless, but our push isn’t to get to that place as fast as possible, but rather to create as much value for our users as we can while gradually making the tech better.
We think this approach – lots of frequent releases, iterating in response to user feedback – is much healthier, and we’re incredibly excited by what the team can do: we have very strong PM, design, and engineering talent that the Bubble community really hasn’t experienced the output of yet because it’s been locked up in the redesign.
What we’re currently working on
-
Performance: we’re now at the point of shifting from investigation to action. We’ve mapped out where the key pain points are, designed and are implementing metrics to measure progress against them, and roadmapped a sequence of projects we think will have dramatic performance improvements. We’ve organized new teams around these projects and plan to commit nine to ten full-time engineers, which is a considerable fraction of our overall bandwidth.
-
Version-control reliability: we rolled out a few more fixes this month, and have reduced the number of incoming bug reports. We didn’t wrap up everything we planned to fix, though, so we expect to continue spending time on this.
-
Migrating code to typescript: the main push right now is to convert from coffee-script to javascript, since going from javascript to typescript is essentially instantaneous. 35% of our codebase is now javascript.
-
SelectPDF replacement: still on ice for now.
-
Bootcamps: our new shorter format, called Jumpstart, which is four sessions over one week, sold out immediately, and the first cohort has been going through the course this week. We think this new format has a lot of potential!
-
New responsive design engine: after numerous requests from the community for an ETA, we are very happy to report that we plan to enter a public opt-in beta by the end of October! The plan is to make the new engine available to anyone who wants to try it out, while simultaneously encouraging template creators to port their work over to it. Once we have enough templates in the new system, and we feel that the new system is stable, we’ll make it the default for new apps going forward. Converting an app from the old system to the new system can be done incrementally, one page at a time. We have an algorithm that will convert pages for you, but it’s not 100% perfect, so we expect users to have to manually test and adjust the output to make sure their design looks good in the new system. While the new system, like the old system, has a bit of a learning curve, the feedback from alpha testers of the new system has been very positive, and as an added bonus, the new system has much better run-mode and edit-mode performance than the old one. So, we are very eagerly anticipating the rollout!
Wishing you all a lovely October,
Josh and Emmanuel
