I work on multiple small multiplayer games. We have shared modules across the front and back end. We split our code into what is game specific, what is library

I work on multiple small multiplayer games. We have shared modules across the front and back end. We split our code into what is game specific, what is library level and what is framework level. We got the simple stuff right the first time, but it's not until project #3 where we are actually building the framework properly. A library exposes utilities that an application chooses to use. A framework constrains the application to a precise system and offers a lot of power within that system. Frameworks are the most risky to write. You should always prefer libraries over frameworks until you are certain not only of the problem domain, but the future of the company. Our first project we really just prioritized features and time to market. When I was designing the golang based backend for our newest project, I spent almost 2 weeks iterating on the design of the framework. The set of constraints around what an API call would do. I implemented a system for syncing JSON objects between the client and server. A system I had been thinking about for 4 years. It works really well and felt good to implement. The constraints I created offer us a lot of power. Logs are automatic and consistent. We can run analytics on the diff of every single player interaction. The constraints guide developers into writing performant code. However there are flaws in the framework. Those flaws could become landmines. Or there are theoretical designs that cannot be represented by the framework, and I have a strong opinion on how to extend the framework to support that. Another dev might implement that new feature in a spaghetti code way. But I can't really justify spending another week iterating on those flaws. When I was pondering where the line is of how long to iterate on the framework level, I was reminiscing fondly of how simple the first products backend is. Each API call written as a unique snowflake, with all its reads and writes and errors in a straight line, and divided into simple functions with no rules. But then I remember the flaws, the database load is high, there are reads and writes going on inside deep function calls. Reading the same record multiple times in an API call. The lack of consistency in the response structure and how the client would deal with that. The lack of completeness of the logs. The inability for us to comprehensively analyze our players data. Abstractions are useful. It's hard to get them right. You're better off dumping all the Legos on the floor before you try to sort them.