

There is also just something very alienating when you work in large teams where each dev only contributes a small component, a lack of knowledge about the system is not only a good thing there but an expected paradigm to create reusable code.
No. That is to say, it might be common, it might be expected, but it is often not good. Every time I join a new team and am exposed to a new code base, I’m astonished by the amount of absolute shit code that results from reusing shit in ways that it was never build with the idea of supporting.
Why? Because someone was focused on completing a single story as fast as possible and they created a dependency they shouldn’t have. And this grows and festers until you have an unmaintainable nightmare.
In order to build solid reusable code you must build it with that knowledge and intent. I’ll cut my rant off there, but I recently joined a new team and the wounds are all very fresh.
All I can really offer is if there are reviewers who review your kind of thing, watch their reviews of similar products, look for what they highlight as really good or bad, and then do what you can to make sure your stuff gets a good review. Then contact the reviewers and offer them a gratis copy in return for an honest review. If you get a good review, that can generate word of mouth that can get you a little momentum.
That’s what I’d do if I were starting on your journey. I don’t know whether it’s a good suggestion or not. Maybe others will come along and offer better.