You have to count the overhead of the system that gets the work to the devs, and 30% on top of salaries for benefits and such.

If you're an inexperienced manager, buying off-the-shelf products for everything outside of your core business might sound appealing.

However, buying a product like this will not make all your design problems magically go away. You have to evaluate the costs of using it over time vs the cost of maintaining your own styles over time.

Using UI libraries is not free. You have to learn how to use them properly. That's an additional cost you pay every time you onboard someone who will deal with your frontend. You have to deal with library updates. You have to solve edge cases they don't cover in a way that doesn't devalue the library.

Some of the worst UI issues I ever faced in legacy software came from commercial 3d party components.

Managers often assume that commercial components will have better first-party documentation and support to the extent that it overcomes community of no-cost components and makes this aspect weigh in favor of paid components.

I don't think it's generally true, but I'm just the one who has to work with them, not the guy with the metaphorical clean hands and literal corner office who makes the decisions.

Huh, but if you have an "we made it ourselves" framework, won't that cost still be there too?

Whereas nowadays employers can just demand experience with jQuery or Angular, because they became standards. Maybe if Tailwind got popular enough, employers can save costs by just looking for devs with experience in them.

In many real-life scenarios it's not a matter of learning a 3d party library or an in-house product. You often have to learn some in-house product regardless and every 3d party library is an extra. It's not nearly as cut-and-dry as many people make it out to be. There are many, many specific questions that have to be asked when choosing whether to write or buy.