Why do I want to use in-house "products" when I could go third party.

I feel like when I build in-house I want a bespoke solution that's easy for MY use case. trying to "productize" it for internal teams is counter productive

Code reuse is important if you want to prevent WET development (We Enjoy Typing over DRY).
Keeping your internal libraries simple, shy-ly built, versioned, tested, and decoupled (all your code should be like this) will go a long way in making your code reusable.
That and shouting about it in the group chats so interested parties can contribute.

Nothing stopping you building what you need. If the behaviour you depend on is tested, internal devs can extend your libraries/modules/services all they like so long as the tests pass (and they're good tests).

Life is easier when there's only one implementation of something to worry about.

TL;DR: build for reusability + communicate its existence with others for adoption = easier Dev life next Sprint

@MammaNeedHummus I find that it's very easy to go over the board with decoupling. and the library loses its value since now Id build another wrapper layer on top to use the library so I can reuse it for *my* use case.

It defeats the point of building something in house when the solution is less battle tested than a third party and still as complex to use

Suitability and experience should guide us. Evaluate the baseline needs and evolve as it grows.

I work on a government OpenID connect auth system and there simply is no sufficiently high-level third-party lib (disclaimer: I co-wrote it)

It's sure as hell difficult to get shared across teams due to technical & political limitations.

Decouple when it makes sense (eg multiple apps/ teams need to have a particular feature)