One day, you’re enjoying the unexpected initial success of 800,000 active monthly users on what was supposed to be a proof-of-concept platform; the next, you’re running a rapid rebuild-from-scratch project aptly dubbed “Speedboat.” This type of energy is what draws many people to startups. There’s never a dull moment. As is par-for-the-course with startups, there have been highs and lows throughout our growth from genesis to V1 and from V1 to V2. Let me take you through the journey.
The first vision of Wonder came from our founders Leonard Witteler, Stephane Roux, and Pascal Steck, who wanted to strike a balance between online meetings and the organic, spontaneous experience of in-person conversation. The founders and five engineers created V1 in about six months. I stumbled upon a write-up of Wonder on LinkedIn, and decided to conduct a hackathon using the platform for the company I was previously working for. It was such a fantastic experience to be able to split into groups, move between circles, and collaborate to problem solve – all while having so much fun that it almost felt like a game. In fact, I liked it so much that I applied to work at Wonder. I came onboard in April of 2021, and since then, I have worn many hats. Currently, I’m an Engineering Manager.
In the first year of operation, Wonder had 800k active monthly users, all through organic growth. During our race to get V1 up and running, we never expected early users to adopt it to such a staggering extent. We knew that people didn't flock to Wonder because of how crisp the AV was; they came because of the freedom and autonomy our platform provided. Still, we aimed to deliver a certain level of performance that simply wouldn’t be possible with V1. We needed to create something more stable.
Like everything in nature, code has an innate degradation toward entropy. We quickly discovered that our ability to make improvements was hindered because any changes created a ripple effect of regressions. As we tried adding more and more features, things started to collide. We were limited in the number of users we could comfortably house in a room before performance issues were inevitable. Users also had to switch between different platforms because our feature set wasn’t robust enough yet. These barriers blocked Wonder from realizing its full potential. It was time to build Wonder 2.0.
We had two possible approaches to get to V2. The first was to take V1’s code and refactor it – essentially do brain surgery while trying to avoid the pitfalls of folding new code into old code. The second option was to gather up everything we’d learned from V1 and start rewriting the code from scratch. That’s what we did.
That approach came with its own challenges. One challenge came from a tight deadline. We had only five months to rewrite everything. The other main challenge came from the nature of trying to rewrite code without repeating any of the issues. There were many features about V1 that were working very well, which we wanted to retain. We sought to rewrite the code for V2 with 80% feature parity of V1.
The main goal was more about creating the ability to have additional functionality without the ripple effect rather than actually creating the additional functionality.
Project Speedboat was the organizational setup that enabled us to deliver Wonder 2.0.
We designed this operation around the knowledge that eventually, your organizational structure will bleed into your architecture and code. Instead of fighting this, we decided to take advantage of it. We delegated teams, which we called “speedboats,” to tackle V1’s problems. One speedboat was responsible for audio/video, one was responsible for the canvas, which includes the circles and avatars, and the third was responsible for everything else, such as server communication, state management, and other UI components. We set them up in a way that each team was protecting its own architectural scope, and thereby inherently protecting the integrity of the application.
This delegation-centered approach worked amazingly well. We started gaining speed in a way that we hadn't before. Our ability to deploy to production, add new features, and test new code was immensely faster than they were when we developed V1. Towards the end of V1’s creation, we were releasing updates once every two to four weeks, which were mostly patches and bug fixes to try to bring back video stability. Today, we release on average five times a day, many days even more than 5 times.
The best moment during Operation Speedboat was the beta launch. I’ll never forget seeing numbers appear on the dashboards, knowing that I was watching in real-time as people explored what we had spent so much time and effort on, and that Wonder was going to succeed in unlocking a new set of behaviors for online engagement. That feeling was immensely satisfying. In another way, however, the moment reminded us that though we’d made it that far, there was still much work to be done before Wonder would fulfill its full potential. That would take more time and more effort, but surely we would get there.
We were, and are, navigating a new space, as no one knows for certain the future of virtual spaces. At the beta launch, we realized that we had positioned ourselves to further help define that vision, which was incredibly exciting and motivating.
Of course, an undertaking of this magnitude comes with challenges. The biggest challenge for this project was the fact that we were solving problems with user experience in mind, but we couldn’t see how users would interact with the finished product. That left us in the dark for five months as we were essentially producing and producing without feedback from users. That was something we expected when we chose our approach, but that didn’t make it less frustrating.
Another challenge was around the WebRTC. In a nutshell, it’s a protocol that allows people to connect from one machine to another, primarily video and audio in this case. In reality, it’s an incredibly complex component. It doesn’t make sense for a startup like Wonder to tackle it ourselves in house, which is why we decided to find a service provider. We were unhappy with the first few service providers – not because they were bad, but because none provided the feature set we were looking for – and we had to drop and start a new integration with another company in the middle of Speedboat, which was very stressful at the time. We ended up working with Vonage, which has been a great fit. We don't just feel like customers of their service. It actually felt like they were partners with us in this journey; they collaborated closely with us to make it a success.
We’ve achieved a slicker, crisper platform for virtual engagement. V2 has improved video stability, audio quality, updated UI, and is being rolled out with a rebrand. V2 is operating on a much more robust, self-grown rendering engine, which allows engineers to make quicker and more effective improvements thanks to a stable infrastructure that supports changing ideas.
Ultimately, we set out to have 80% feature parity with V1 and achieve a high level of flexibility and speed to adapt to any given situation. And in those aims, we were successful. Here are some of the ways that V2 realizes and expands upon the vision of V1:
For the immediate future, we have a lot planned for Wonder’s updates. Many of our plans center around user experience, ranging from functional ways to share content, such as giving hosts more tools for content sharing, allowing users to consume content within Areas, and providing cues to help guests interact and start conversations. Other plans are geared toward the fun aspects of using Wonder, such as a Christmas mood that outfits users with Santa hats and other winter-themed fun.
The rapid progress we’ve made to get from Wonder’s genesis to Wonder 2.0 has been a thrilling experience, and we can’t wait to see it in action. It is an honor to be part of a team that is shaping the future of virtual spaces.