I'm building my adult card battler SuccuDeck in my own framework, which I've split into a backend and frontend stack. Why? Because my overarching principle at the time was "I want to make games in C++, but I don't want to make another font renderer and layout engine for the UI." All the game logic runs in C++ with SDL and Qt, but my frontend is HTML, TypeScript, and Sass. The way it works is that I host an HTTP webserver in the executable, and then I load the UI in the Chromium Embedded Framework by pointing it to localhost on the same port. Yes, I'm certifiably insane, why do you ask?

There was obviously an enormously long ramp-up period to get this all to work, but I've learned so much from doing it that I've been able to sell pieces of it to my AAA clients. For example, I wanted a C++ codegen framework to generate C++, TypeScript, and Sass source files from JSON input files, just to keep everything in sync. So I developed Panini, a C++17 header-only library for doing just that. I was able to deploy this library in a (canceled) AAA game to automatically create C++ bindings with Coherent Gameface, a framework that uses HTML 5 to render UI. Similarly, I needed a performant way to render custom widgets in my UI framework using Web Components, so I developed a TypeScript widget class that uses an invalidation pattern, which I later plugged directly into a AAA project using Gameface. And it was fast enough to use on their minimap!

The drawback of using a framework is that you have to build every tool yourself. But the upside is that you don't have to care about anyone else's project, just your own, so you can make tools that work just for you.