Nuri — formerly Bitwala; How To Manage An Ambitious Rebranding

This is not a marketing article. This is my way of appreciating everyone’s hard work and talking a bit about my experience, and showing the challenges we faced.

Near the end of last year, I was stopped in the hallway of our office (in between Covid lockdowns) and was asked to lead the technical side of the redesign and rebranding efforts of Bitwala to Nuri. Since I was building the Bitwala products for all platforms from the very beginning, it only made sense for me to jump into that opportunity head-on.s

We, at Bitwala (and now Nuri), are always working on building many new features. Most of the time, everybody’s busy with their own projects, and it’s difficult to get people on a new one before theirs are fully finished and released. That resulted in a decision to hire several teams of freelancers to help us out. Obviously, there have been many issues with this approach, but you might say that it was done for the greater benefit. It was really important for us not to stop any other feature work.

With that, it was almost certain that this project will not be a perfect case study of how redesign and rebranding should be implemented. And since I took ownership over the tech side of it, I was left concerned about what this would mean. It would surely be better implemented by people who’ve spent years building the product in the first place. But that’s not to say freelancers couldn’t and didn’t deliver the best they could. They certainly have.

With this very uncomfortable situation on our shoulders, we were left with trying our best.

First off, we needed to onboard all the new people very quickly. Deadlines were very tight, and the amount of work was considerable.

Stage 1 — Hiring

Hiring experience at Bitwala tends to be very hands-on. There are usually two rounds of hiring that are in the hands of employed engineers. Interviewers are generally from the teams that’ll end up working with them. That makes it easier to assess whether it’s the people the team is going to be happy with.

In the beginning, I was the only engineer in the project. And since there was a severe lack of people’s time at Bitwala, the best way through this we could find was to hire a lot of freelancers very quickly.

There’s a cost to that. Unless the company has a very good and quick onboarding process set in place, this will take time. Unfortunately, it was time and resources that we didn’t have. Therefore it was critical to speed the process up. To decrease the amount of time, I increased the specificity of the requirements, created a new coding challenge besides the one the company normally used (with some adjustments to it later on; the first version wasn’t perfect), and all-around focused the hiring to cater specifically to this project.

First in the process is a technical interview that’s then followed by the coding challenge. All of this went way faster than I’d usually like it to be. But I tried my best not to compromise on the quality. Both the quality of the interviews and also when it came to the time spent on evaluating who do we give a chance to help us.

After a couple of weeks of this very accelerated hiring process, we had 3 small-scale teams of competent engineers that were ready to take on the ambitious challenge of redesigning our native app. Later on, we repeated a similar process for our web app, for which we had one bigger team.

Stage 2—Getting To Work

As ambitious as Bitwala is, there were a few things that we were lacking. Due to the huge amount of work on new features, our processes were not set up in a way that'd allow us to get new people up and running all that quickly. Another problem was a considerable amount of technical debt, which meant onboarding new people took even more time. That was a very big risk to the entire project. If we didn't get people up to speed quickly, we'd lose our very valuable time, and that'd risk the delivery.

My role was fairly clear. Set up the project and all the teams for successful delivery with as few problems as possible in the process.

Along with a specific hiring process, we also had a specific definition of done and certain other processes. That was critical as that also helped us to get started a bit quicker. Compared to our regular definition of done, we’ve had several changes:

1. The review process required the approval of two specifically Bitwala employees. At Bitwala, we usually require at least two people to approve the work before it gets into the codebase. As I wasn't ready to lower our standards and since these people were all new to our codebase, the review process initially required one approval from me and one from an engineer of an appropriate squad (one for each redesign team).
   
   (After a couple of weeks, when we were assured of the quality of the code, we gradually relaxed these rules to allow for faster delivery and more autonomy of the redesign teams.)
2. Any changes can't impact the current apps. As all our changes were deployed to production and were just hidden behind a feature flag, it was imperative that we didn't change anything in the existing app. Building a new app entirely wasn't an option (and I'm going to be talking about that later in the next more technically aimed article), and so we needed to migrate as much as we could as easily as we could. Therefore we knew all our redesign code is, in fact, the production code. So we treated all changes as such.
3. Change requests required screenshots. This was a very visual project. And as we had a limited amount of reviewers, having screenshots of every state of the app was a faster variant of reviews. The alternative was only to run the code manually and check visuals. That'd be unworkable. This rule really helped us to get valuable visual reviews quickly and with a little effort from reviewers.

With these changes to our definition of done, we addressed the few risks I mentioned earlier. It helped to maintain quality code while improving delivery time where possible.

Having these risks taken care of early on resulted in zero breaking changes into our production app.

That, for me, was a major achievement.

Stage 3—Adapt

A value that was the root of Bitwala's existence from the very beginning.

The processes set up at the beginning were working well for some time. But as new challenges came up, we had to adapt.

As you can imagine, this project was very ambitious from the very beginning, and it came with many challenges. One of the major ones was the fact that we had other ongoing projects in the company.

As I said before, we are always baking something new at Bitwala (now Nuri). Therefore the rebranding wasn't the only project at the company, and we had a couple of other ambitious features in development. That might be fine with other projects, but the rebranding fundamentally had to touch all parts of the product, and that included the parts that were still in development by the other teams. This was another major challenge.

That meant that we needed a focused effort on not just breaking current functionality but also the future functionality. We had to keep in mind that our delivery also doesn't limit the delivery of other teams.

The only solution to this was to increase the communication between the teams and continue with targeted reviews. The communication meant more meetings, and the time was scarce. But it was unavoidable. The targeted reviews were already happening. People who'd work on a certain feature would be in the reviewing process of the redesign work that'd touch the feature. We've done targeted reviews as much as possible since it meant we could avoid having to have everyone in the loop, and it'd help us avoid bugs more effectively.

This wasn't the only setback that we needed to adapt to. But it was one of the major ones. When working on a product-wide project that changes everything, challenges like this were always certain to pop up.

Stage 4-Nuri Grand Release

Probably the most difficult part of the entire project. If we had to adapt during development, in this phase, we needed to adapt way more. That doesn't mean there was a lack of planning. It meant we had several plans, and they kept changing as we were developing a better way to execute this last phase.

Before our planned release date, we had set up a specific time for code freeze and also a period for testing. Achieving code freeze was difficult enough. Not merely because we wouldn't be able to finish but because of the noticeable high standards that every one of the developers and product managers had. It only goes to show that we have a team that's very dedicated to delivering their best.

On the night when the code freeze was meant to happen, we found a bug that would prevent testing, and it'd also mean we couldn't roll back the app in case of an issue. That was something we needed to deal with on the same day, or we'd set our plan back. As mentioned earlier, Bitwala (now Nuri) is very lucky to have a great bunch of people dedicated to their craft. Several people, including me, were working very hard on fixing this and a couple of other things in the evening. And we pulled it off on the very day.

I'm completely convinced that it's the dedication of the engineers working on this that made us make it through challenges like this.

At the testing phase, we found a couple of new issues (as one does when testing). Some of them were caused by the technical debt acquired over the years of rapid feature development at Bitwala. Others were regressions from ongoing projects. And some were tied with the redesign itself and its challenges.

From the very beginning, the redesign project wasn't meant to be the project that'd cope with the existing issues. If it was, it'd be impossible for us to deliver it in the set time frame. But when we could improve things, we did. Therefore we put most importance on any new issues that popped up, but at the end of the day, we actually did improve certain aspects of the product besides the massive effort that was our redesign.

We made it through that all. And there it was. The product we spent months crafting was alive and out there in the world. You can check it out on https://nuri.com/.

On a personal note, this was my first project where I did only little coding myself. Praise for building components and migrating screens goes to the quite large redesign team. All product managers, designers, and developers did the best job they could do in our limited time frame, and they deserve a shoutout! Also, shoutout to everyone else involved in Nuri redesign, this effort was company-wide, and it's been a pleasure to see so many dedicated people in one place.

In conclusion, this was by no means a perfect project, and the solutions we've had and decisions we've made were not perfect either. But in the end, we adapted with every setback and delivered. And even better, we delivered something we can be happy about. I hope all of our existing and new customers enjoy the new design that many people at Bitwala (Nuri) spent months crafting!

If you want to read more about technical decisions, I wrote a follow-up article that's going into the technical details: Nuri — formerly Bitwala; How To Migrate A Brand.