Yeah, I get the “I like to understand how everything works” angle, and I like implementing things from scratch in personal projects. When working with a team, I

Yeah, I get the “I like to understand how everything works” angle, and I like implementing things from scratch in personal projects. When working with a team, I feel it really depends on the team and the business. I think if you’re extremely focused on quality, and don’t need a really rapid pace of development (especially in the earlier days), then going low/no dependency can make sense. It’s certainly working for SQLite! On the flip side … some of the worst software mistakes at places I’ve worked at have been of the “let’s build some common thing ourselves” variety. For example, for some crazy reason, someone implemented their own HTTP-esque protocol on top of ZeroMQ, complete with servers and clients in multiple languages, that was used in a massive number of services. A total disaster, insane amounts of dev work invested in it, tonnes of bugs and performance issues, eventually we ripped it out and replaced it with HTTP, but it took literally years of work to do so. Less extreme were in-house service discovery tooling, and an in-house version of something like Redux. Tonnes of investment to build them, poorly documented with poor test coverage and lots of bugs. Then the main author/advocate leaves the company, it becomes a huge maintenance burden, and eventually it’s ripped out and replaced with a popular open source version at great cost/effort. In all cases, the in-house version was massively lower quality than the top open source alternatives, in basically every conceivable way. I agree that introducing a dependency is a significant decision, you should research the dependency well and not add it lightly. But building everything in-house can be a major mistake with massive unnecessary costs, you need pretty specific use cases and the right company culture for it to work out.