Other reasons are possible, too. 1. When they started, pre-existing frameworks weren’t such popular nor standard. 2. When they started, the functional require

Other reasons are possible, too. 1. When they started, pre-existing frameworks weren’t such popular nor standard. 2. When they started, the functional requirements they had were very different from what the product grew eventually. Many software projects start small and grow. 3. Couple times in my career I worked in projects where management didn’t believe in functional specs, the requirements changed dramatically in the middle of development. With large libraries, some changes in architecture are handled by replacing the library with another one. Quite expensive to do. An in-house library can be more flexible, just because it’s less code. I’m not saying making in-house libraries was justified in your case. Maybe it wasn’t and that developer did it mostly for fun. Just the trade off is quite complicated, and your reasons are not necessarily that bad. In many cases, I think it’s technical management’s job to make the decision, i.e. evaluate alternatives, maybe allocate resources to make a prototype. Also, from the management standpoint, if a developer can write their own frameworks, there’s very high probability they can use existing ones. Maybe it makes them slightly less happy i.e. need to pay them more to compensate, but they’ll do the job. The opposite is not true, there’re people skilled at combining libraries and copy-pasting third-party code who can’t write their own code.