> I think they should have just gone with an off-the-shelf library. This is typically not the case in larger orgs with products that need a consistent, unique

> I think they should have just gone with an off-the-shelf library. This is typically not the case in larger orgs with products that need a consistent, unique feel and branding - that's why you see so many design frameworks popping up. Or sometimes you just want components for a particular tech stack (though you could integrate one of the existing ones with your JS/TS codebase, too), which is also what HashiCorp has done here (components for Ember.js). However for smaller teams I don't think that this approach makes much sense - I've seen 5 person teams spend time on creating their own component library when it felt a lot like bikeshedding, when there was actual functionality that needed to be implemented first. For most out there, just grab Bootstrap, or something specific to your front end framework/library like PrimeVue/PrimeNg/PrimeReact and first make it work, then consider customizing it. Then again, you don't see many companies out there with products that look like they're out of a Bootstrap tutorial, so go figure. I've actually heard people disliking fonts like Open Sans as well because of how common they are - seems like many want to set themselves apart. Not sure how much of a worthy goal it is, there's nothing wrong with software that works but looks a bit boring (as long as the UX is great).