Writing a piece of code and seeing the output of that on a developer’s machine has become much trivial with latest tools and frameworks that we grossly underestimate the cost of maintaining code once it is written. It is observed a lot in the UI code where the impact on productivity is huge.
Last year during one of the discussions about developing a new product which has to be tested for product market fit, we made sure that the designers had to use directly off the shelf components of Vue.js through Element. Initially though there was a bit of hesitation from the designer later on we collectively realised the gain.
When designers used only ‘off the shelf’ components, they were able to create screens that were too easy to translate into code removing the resistance to move things from idea to production. As there were neither custom components nor custom interactions, we did not have the need to have a huddle with the design team often to figure out if something is doable or not.
Though there is a risk of non compatible upgrades in third party software, the workaround is much simpler compared to the pain of going through the maintenance of custom components.
The tendency to build ourselves is very high when there is a cost to introduce third party software, but the same inertia exists in adopting open source work as well unless the frameworks like spring are ubiquitous.
Novi's 
Couldn’t agree more Vinod.
This is wonderfully written insight on problems of today’s custom and complex world.
Curious to know, have you had to do any workaround on any component? Also, was the design provided by Element in alignment with the design system of your project?
We had restricted the experience and design to what element provides so it was easy to stay within the bounds
Ah okay, makes sense. I worked on a UI components library and was curious to know about these wrt your project. We questioned ourselves on whether a components library makes sense and concluded that it did to some extend because of the design system followed in the organisation, the look and feel were not provided by third party libraries (in our case we mainly relied on PrimeNG) and it was not easy to configure the components provided either. It wasn’t easy to build components either, especially as teams that were supposed to use our library had started their dev work few months earlier.