The problem is that the author most probably chose some libraries than went out of fashion or started stagnating and ran into some bugs or lack of documentation

The problem is that the author most probably chose some libraries than went out of fashion or started stagnating and ran into some bugs or lack of documentation that drained time. Its impossible in JS to not have made bad choices that didn't last or cost huge amounts of dev time to workaround. The real key to politics is building up enough political capital to be able to survive when things go south. If you continuously make bad decisions you will inevitably be fired. Even if you were always learning from them each time. I would say: - communication - here is why and how we made these decisions and the assumptions we followed. if they turn out to be bad choices, here is where our assumptions were wrong. we are going to learn from them in the future. - management buy-in - you need the CTO to buy into your decisions and reasons and not just to trust you to make them. let them make the decision. avoids the blame game in the future. - avoid shiny things - you have to stick with what you chose and focus on delivering business value rather than always thinking about that re-write or the new shiny thing. work is going to be less fun and you will feel like saying "a rewrite to this library is going to make us more productive" but it rarely will and unless you have a strong CTO its always going to be hard to justify.