I work at a medium company that is in a comparable sector implementing comparatively performant and externally constrained things pretty much wholly in C and pretty much wholly with our own dependencies with external dependencies being mostly located in ops, testing/qa and other stuff not in the critical path of what the people who pay us want the products to do. For us it's not about "built here" it's about control and uniformity. The company is a decade old and very profitable for its headcount though not subject to wild delusions about future hockey sticks because of what we build and for who.

So the approach clearly can work. It won't kill you. But it's also unclear the degree to which this approach contributed to vs detracted from our success since it's not like there's a control company that did it the other way you can compare to. It takes constant effort to do things this way, but so does managing dependencies. While unilateral control, and the responsibility for that, that comes with writing your own dependencies is a key aspect of how we do what we do with the headcount we do it's not like it's part of our marketing. It's just a decision that was made that we're sticking to because it seems to work for us. It's not some silver bullet, it takes effort to do well, like anything else done well.

I have worked at huge companies where they were biased toward using existing stuff where it existed and tweaking it just the bare minimum needed and that worked very well for them too and definitely had its pros too.