Every single company I know (except our forward-looking customers, of course) are creating a testing framework.
It usually goes like this historically: first tests are simple plain Selenium, but as your team grows people tend to start extracting common code in testing frameworks.
The supposed to help people to develop tests faster. Well, they do a little bit. But need to be updated since most of them will rely on XPath locators, and, therefore, they get out of date every time product changes.
However, why would need to do it in the first place if you can express what needs to be tested in plain English like this: https://blog.testrigor.com/natural-language-recognition-for-software-testing/
... click on "Add to cart" click on "cart" enter "San Francisco" into "City" ...
On top of it, you can define subroutine "add pants to cart" and do it like this:
add pants to cart click on "cart" enter "San Francisco" into "City" ...
The approach testRigor has is dramatically more stable since it relies on how people work with the page regardless of underlying structure. That allowed our customer to compare our tests with their own Selenium test suite and they found that our testing is by far more stable up to a point there it doesn't make sense for them to support their own code.
Are you still writing your testing framework?