Turning the Page: Preply’s Successful Journey Through the Rebrand
Many companies undergo a rebranding process, and there are numerous resources available on the internet that discuss its implementation from branding, marketing, or PR perspectives. But what about engineering? What happens when you have defined your brand strategy and guidelines, and now it is time for the engineering team to actually code those changes? Is this an easy task? In the real world, where each software project has tech debt, legacy code, and other hidden complexities, it quickly turns into a project consisting of around twenty engineers working on it for several months. In this article, I will try to focus more on the practical details of how we ran our Preply rebranding from an engineering perspective.
The Context
Preply is the leading online marketplace that connects students with top-notch online tutors from all over the world, giving them the support they need to have personalized language classes with AI-powered tools and content.
The company was founded in 2012 and has gone through a couple of rebrands since then; the closest one was in 2021. Back then, it was performed by a small in-house team, more focused on more modern visuals rather than a bigger brand idea. As a result, the rebrand stretched over time, and the site was rebranded only partially, having some pages with legacy design or even a combination of two new and old ones. Net-net: It was a little fragmented.
At the beginning of 2023, the company decided to rebrand again. But this time, it was a much bolder move:
- Preply involved an external agency to help us build a brand vision and foundations with a big idea in mind
- It was tied to the company principles that were in the process of evolution and shifting to bigger projects vs smaller experiments
- It was made a company-wide #1 priority for all chapters and functions
- It was planned for 6 months of work (spoiler: it was delivered just in the nick of time).
How it started
In this article, I’m focusing purely on the engineering aspect of work so I’m omitting the details on how the brand vision was formed and how brand foundations were built and transformed into product decisions and visuals.
While the Brand team was working on all the above together with an external agency we already started working on Engineering strategy and thinking about how we would deliver the rebrand.
We created a Rebrand Core team consisting of:
- 3 Senior FE engineers
- 6 Senior Designers
- PM and EM
Together with the Core team we built a plan and crafted a process to work with other Product Designers and Engineers. Our work started way before the actual designs were ready and even before any brand foundations were settled.
What could the engineering team do at that stage (a few months before coding)? Well, actually, a lot!
The Rebrand Core team began by creating a detailed plan and a handbook for product developers, outlining the necessary steps they would need to take. They also defined the process for coordinating the work of all involved parties, which included over 40 front-end developers and 15 designers, the Core team itself, and, of course, other stakeholders.
Do we have a Design System?
A Design System can be quite helpful for a rebranding, especially in our case, as we tried to limit UX changes and focus on “repainting” first.
We had a Design System in place, but it wasn’t fully mature, with only a limited number of components developed. Additionally, its second issue was the need for more product coverage provided by the Design System (DS). We could not invest in creating more DS components before the Rebrand as we didn’t know the peculiarities of those on the new brand so we decided to increase the coverage.
It was an excellent moment for that as the rebrand was the sole priority of the whole company. This allowed us to approach every product team, and they readily accepted the initiative of increasing DS coverage, unlike other times when it could have conflicted with their product priorities. It was easy to sell, too. Migrating all components to the design system would significantly shorten the actual rebranding process. With just a change to the design system theme, all components that come from the DS would be rebranded instantly.
That kept most of the Product devs busy even before the designs of their pages were ready. Was it time to relax for the Core team? As it turned out, not really.
While Product devs were migrating components of their pages to the Design System, the Core team of FE engineers was busy with:
- Preparing the solution for new fonts. The challenge with fonts involved transitioning from a single font for the entire site to needing three different fonts — one for headings, one for body text, and a fallback font for unsupported symbols like Cyrillic letters. This complexity required ensuring that multilingual pages maintained consistent font usage and appearance on both web and mobile platforms and that the website’s performance remained unchanged despite the increase in font variety. We cared about web vitals from Google, namely CLS, which can be affected when a custom font is loaded and applied by page.
- Rebranding DS components and adding a new DS theme so that we could actually do the magic switch and repaint a big portion of the site “automatically”.
Library of UI components in addition to DS
While working on these activities, we realized that once designers start providing mocks of rebranded pages to engineers for implementation, the engineers will face a need to code common UI elements, that were not initially present in the DS, from scratch and multiple teams will be coding the same components simultaneously. It seemed very inefficient.
So, we needed to up the speed of the rebranding of the UI that was not built with the DS. One solution could have been adding more components to the DS, but iterations over the DS are slow while we have 40 engineers and a lot of parallel tasks.
Our solution was to develop a sort of “beta Design System” built based on unstyled UI libraries. This system would allow us to build new components quickly and place them closer to user-facing code, making it much easier and faster to release them.
We investigated several options and ended up using Radix, which helped us build components very fast. The advantages included decent quality, consistency among product teams, and components prepared for future accessibility needs.
The Rebrand Core team coordinated the efforts, distributing tasks among the available product developers. This collaboration led to the creation of 32 new components. Alongside the existing DS components, these formed a comprehensive library that significantly streamlined our development process.
To test or not to test
At Preply, we have a very strong experimentation culture and almost religiously believe that we should A/B test every change in the product (read more about it here). So, when we were planning to repaint 70% of our site, the question arose: should we A/B test this change? After lengthy consideration with the Leadership team and our in-house experimentation team, we decided not to A/B test the change. The main rationale behind this decision was that we wanted to create a ‘wow’ effect for all our users immediately rather than delaying it. Additionally, we consulted with other large marketplaces that had undergone similar changes and did not observe a significant negative impact on the business. Also, a Rebrand is a one-way project, and you can’t go back 🙂
However, this decision involves certain risks — you can experience a drop in business metrics or miss bugs. So, we had to decide on our mitigation strategy for those risks and come up with a couple of solutions:
- Flags per page. We developed each rebranded page under a flag (35 unique flags), which allowed us to roll back specific parts of the site if any issues arose. Additionally, this enabled us to test the old and new versions of the product simultaneously in production.
- Testing. For the Rebrand project, we established the whole QA strategy that involved gated manual testing by the team and other Preplers. We don’t have an in-house QA team, but we involved the whole company in testing as we’re all users of Preply. Preplers were super passionate about finding bugs; surprisingly (or not 🙂), our CPO became the best tester and reported the biggest amount of bugs. Additionally, we set up a separate mode for our E2E tests to run them against rebranded pages to make sure nothing was broken.
- Real-time monitoring in Amplitude and Looker. Since we decided not to launch the A/B test, we lost the opportunity to see the impact on the business metrics and had to redefine it outside of our A/B testing framework. We went for two layers of monitoring: Global and Per Team.
- On the global level, the data team set up the dashboard in Looker to monitor the North Star Set business metrics in real time.
- On the team level, each squad set up an Amplitude dashboard with the most important conversion that represents user behavior. It was a crucial layer as one bug at the beginning of the funnel could screw monitors for a lot of teams and absolute numbers on global dashboards. So we ended up having dozens and dozens of conversions to watch during the release time, but it was worth it.
- Gradual rollout. Where a standard A/B test setup is typically launched for 50% of the traffic, we decided to go for a gradual rollout from 5% to 25% and to 100% within two days. We had a go/no go check-in with all the major stakeholders at every decision point. The app release was also done gradually and started with 1%, together with the full scale of the web, and progressed to 100% within several days. This approach gave us a bit more control over rollout and the possibility to identify issues on a smaller portion of users and postpone the full scale if we saw major issues.
All of that ⬆️ was included in a very (very!) detailed rollout plan that indicated who-does-what-by-when which was was fully aligned with all the involved people and stakeholders.
Release Day
The Big Day has finally come. Six months of hard work all lead up to this. You can feel the energy in the air, a mix of excitement and nerves, as everyone’s efforts and decisions come together. Hours upon hours of intense work and endless discussions are woven into every detail, and the place is buzzing with activity. Conversations flow, blending strategic planning, nervous laughter, and those final final checks. The vibe is electric, and everyone is focused on their piece of the puzzle, making sure everything is perfect.
As per our extensive release plan, we started with a 5% launch, and the first users started seeing the rebranded site! A few hours later, we scaled to 25% of the traffic — all on the track up until that point. During the end of the day check-in we were notified by one of the LT stakeholders about a bug they noticed on one of our main public pages. So, we declared an incident, and the investigation began. Fortunately, within a couple of hours, together with the team responsible for the page, we identified the reason and fixed it. Surprisingly (or not) the bug appeared to be old, not introduced with rebrand. You learn a lot about your product when you need to repaint it and find some issues that you never knew about. Thanks to the Rebrand, we fixed dozens of old bugs, making Preply better and better.
The next day, we met together again in the same room (or Zoom :), and after a thorough review of all the dashboards, we decided to go full-scale for 100% of users! Success and happiness! Everything is going according to plan! Or is it? 🤔
Post-launch
Till this moment, everything went as smoothly as possible for such a big project; apart from one bug that appeared to be historical, we did not face any medium+ issues. However, after full scale, we started seeing weird deviations in the number of sign-ups.
We saw a 30% drop, which was significant and, dare I say it, scary. So we declared an incident and started an investigation with the very best Preply minds. The team spent a sleepless night, and the next day, we found the answer.
The issue appeared to be two-fold and caused by the historical bug from one angle and a decrease in marketing spending from another. It was extremely difficult to locate the issue so once we confirmed our hypothesis was correct, the whole company felt relief. Finally, time to celebrate!
Conclusions
We can definitely call the rebrand at Preply a success story: we delivered it on time, we did not break the product, and we did not experience a drop in business metrics. All of that was possible thanks to disciplined execution, dedication, and commitment of the whole company.
This project was a marathon, not a sprint. Maintaining a high pace was difficult at times, especially at the end of the project, but we managed to create an amazing synergy between teams and, despite the intensity and difficult times, most of the engineers involved in the project shared very positive feedback and appreciated it as one of the most prominent projects in their career so far.
Here is what our engineers said
“Seeing dozens of people from different chapters and teams working on the very same goal is very inspiring. It had a significant positive impact on Preply culture and the way we collaborate”
“It was right to build the missing part of the Design System outside of the existing library without constraining us with backward compatibility. Given our relatively low automated test coverage, it was right to fall back to manual testing.”
“Seeing a 30% drop in conversion to registered users was one of the scariest moments of my life. What a relief it was to find out it was actually a historical bug that we fixed within the re-brand. Win-win!”
“Engineering was told it’s going to be just a simple repainting with a color change, but we knew we must prepare for much more exciting changes ;)”
“We worked hard, but it was lots of fun! One of the most memorable projects in my career.”
