Nuri — formerly Bitwala; How To Clean-Up After A Successful Rebrand

After the project is released and it's out there. A code clean-up is in order.


At the point of release, we already had set the redesign feature flag to true by default on the production environment.

Step By Step

Let's start with a list of things that we'd want to get rid of. And let's put them in order in which we're able to remove them as in some cases, they depend on each other.

  • Old screens and their logic. These are screens that are no longer used anywhere. They belong to the Bitwala app only and are not even navigated to in Nuri app. Technically, they're still accessible but only in local environments. They are hidden from production.

    For screens that were replaced with the same name, we introduced .deprecated.tsx suffix and migrated between the two in their appropriate index.tsx. We now could simply remove the deprecated file and export directly only the Nuri version of the code.
  • In-screen migrations. When migrating a screen didn't require many changes after the initial component migration, we were able to change just a few details. This saved us valuable time earlier as we didn't need to rebuild the entire screen.

    As opposed to the previous step, this requires changing more of the Nuri code. But the changes should've been more minor in the first place. This requires removing the redesign flag from the screen-level components.
  • Feature-specific utilities. This step may not be necessarily required. But if we already know we're not going to use a certain utility function or if we already have a better version of it, it's better to remove code that's not used and therefore probably not intended to be used anymore. What could happen is that someone could import this older version of the utility function and expect it to work like the newer ones.
  • Deprecated shared components. Whether it's UI components or components with functionality that was used across teams, it fits into this category. This is a very tricky functionality to change or update. Doing so requires attention from every team and obviously also heavy QA.

    What makes this a bit easier is that we also approached migration of components very similar way to migrating the screens. So removing deprecated components would require removing .deprecated.tsx file from the component folder and adjusting export in index.tsx file.

    That's is where planning for cleaning up after a project really pays off.
  • Theme migration. This would be the overall theme of the app and also the web app. Since any of the steps above may include the usage of overrides of old colors, we needed to preserve this until the very end of the clean-up.
  • Redesign feature flag. At last, any functionality relating to redesign feature flag setting and its overrides can be safely removed if there's no more conditional code depending on the flag.


Due to the way we approached migration, cleanup couldn't be done in all cases by simply removing certain files. For example, to make components different, we'd sometimes migrate even overrides so that we wouldn't need to go and change overrides one by one. What this means in practice is that if we'd have a Button that has a default blue color, but we'd decide to override it with another blue

After this process is finished, it will leave us with way cleaner code that'll be more maintainable for everybody. It will be less prone to bugs and developers will be able to implement new features more quickly without worrying about legacy code introduced in the redesign project.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store