After investing time and money developing an application, it can seem counterintuitive to start from scratch to update it instead of just working to improve what you already have. But sometimes a clean slate is the best option.

Spotify recently updated its web app and it did just that. When doing so, it had to reconcile the fact that what worked well for the application when it was first launched was maybe not the best design at this point in time.  The team has released a blog post sharing the thought processes behind the decisions made when making the new web player

Launched in 2012, the original web player was designed using the same approach as the desktop application. Views were isolated using iframes, which allowed the development team to add and release new features without messing with the rest of the application. The code was also the same on the desktop and web player, which meant that it was very easy for new features on one player to be made available on the other.

But that architecture had its flaws, the company explained. It was fine for the desktop application to have iframes for each feature and for the user to download the necessary resources when needed. But having to download new resources every time the user navigated to a different view was resulting in long load times, which was affecting user experience.

As a result, in 2016, Spotify decided that the current architecture wasn’t working for them. It was hard to maintain and it was preventing the team from creating a better product. This led the company to make the decision to start from scratch.

While looking into how feasible it would be to rewrite the web player view by view, it also started making a prototype that followed a similar architecture to the TV application.

According to the team, these were a few of the reasons that the company decided to completely rewrite the web player instead of trying to improve the one it already had:

  • The system that provided the code for views wasn’t used by the desktop application and was too complex for the web player
  • The web player was based on a lot of outdated libraries and frameworks
  • The web player was initially built by 40 developers across different teams, but would now be maintained by just five developers
  • It was slow to iterate on, especially when the team tried to make changes across multiple views.

According to the company, once it made the decision, it only took a few weeks to build a Minimum Viable Product. After it had that, it did extensive user testing and used that feedback to keep improving the product. Now, the company has determined that in performance tests, the new web player is outperforming the old one across all key metrics.

Spotify’s experience may prove to be a valuable example for companies in the same position. While it may be an expensive and time-consuming process in the short-term, making the decision to completely rewrite something may be better in the long run.

Rather than spending unnecessary time trying to add features to an application that may not have the perfect architecture for what you’re trying to do, you can get a fresh start that is more inline with the current technologies and trends.