I'm not the person you ask, but we use fullstack Typescript in our dev department. We're a weird mix of a green energy company and an investment bank, so inhouse development is very small-scale, and this means you share resources. Using one language for everything helps with this, since the one person who is really good at React can take a vacation or a sickday without being glued to a laptop since everyone else can also work on the front-end even though it's not their daily thing (and vice versa). More than that though it lets us do things like code reviews, troubleshoot solutions and generally work together really well, even though we're working on very different projects. It also lets us build libraries that can be used for everything. One example is our ODATA query and client library, which makes it incredibly easy to debug issues related to it, because everyone uses it.
Anyway, the one place where Typescript isn't great in the fullstack approach is the Database stuff. We used Prismo for the better part of a year, until we eventually moved on to Mikro-orm which has been great so far.
I'm personally not a big fan of OOP or "over architecture", because I've seen how bad it can go too many times. Instead I favour functional programming and keeping things as simple as possible, even having "almost duplicate" code once in a while. So with this in mind, it may strike you as odd that we moved from Prisma to Mirko-orm, but Prisma just clashes with the way we want an ORM to work in so many ways.
Maybe this is by design. Prisma doesn't want to be a "real" ORM after all, but things like having to put everything in a single schema file is bothersome. Yes, you can put it in different files and then cat them together, but that leads to other issues. Like the VSC Prisma extension highlights not working outside the main Prisma.Schema file. More than that though. We like to have "ID, UpdatedAt, UpdatedBy, CreatedAt" sort of things on basically all our models, and since Prisma doesn't have the inheritance I almost never use, that means you need to duplicate it soooo many times. It's also hard to write generic methods for basic CRUD stuff because of the way Prisma uses the Prisma Client Classes it auto-generates to operate. On top of that, migrations can't go backwards in Prisma.
Some of these issues are on the Prisma road map, others aren't, and you're always going to bang heads with an ORM, but Prisma just didn't feel as mature as it's extremely excellent documentation (and marketing) might lead you to believe in my experience.
I can certainly see myself using it again, once their roadmap is a little further ahead though.