There is a moment, usually around month six of a serious project, when the framework you picked stops being a tool and starts being a coauthor. Its assumptions have soaked into your codebase. Its idioms have shaped your team's vocabulary. The parts of the problem it makes easy have become the parts you focus on; the parts it makes hard have quietly drifted out of scope.
This is not a complaint. Frameworks are supposed to do this. That is the deal: you trade some autonomy for a lot of leverage. The leverage is real. The cost is also real, and it is almost never discussed at the moment the decision is made.
Frameworks are worldviews
Every framework encodes an opinion about what a program is. React thinks a program is a function of state. Rails thinks a program is a bureaucracy of resources. gRPC thinks a program is a contract between services. These are not neutral technical choices. They are metaphysical commitments about how the world should be modeled, and they propagate outward from the code into how your team talks, plans, and argues.
You can tell which worldview a team has adopted by listening to their standups. A React team talks about state and effects. A Rails team talks about resources and controllers. A microservices team talks about contracts and boundaries. The vocabulary is the framework, made audible.
None of these vocabularies are wrong. But each of them makes certain thoughts easier to have and certain thoughts harder to have. If your problem happens to align with the framework's worldview, the framework is a superpower. If it doesn't, the framework is an ongoing tax you pay in translation cost, forever.
The tax you don't see on the invoice
The tax is invisible because it is paid in a currency nobody tracks: the ideas your team didn't have because the framework made them hard to express.
Consider a team building a real-time collaborative editor on top of a request/response framework. The framework is not stopping them — everything works, technically. But every conversation about the product routes through a mental model that assumes discrete requests. Ideas that would be obvious in a streaming worldview arrive late, if at all. Features that would be one line in a CRDT-native system take a sprint. The team ships, but they ship the version of the product that the framework was willing to let them think of.
This is the real cost of an ill-fitting abstraction. Not the code you write, but the code you don't.
When to fight the framework
Most of the time, the answer is: don't. Frameworks earn their leverage precisely because you don't fight them. The moment you start writing code that argues with the framework, you have lost most of what you were paying for.
But there is a specific case where fighting is correct: when the part of your product that matters most is the part the framework makes hardest. If the differentiator of your business lives in the framework's blind spot, no amount of leverage on the other 90% will save you. You will ship a product that is competent everywhere and remarkable nowhere.
In that case, the honest move is to either replace the framework or write the differentiating part outside of it — as a separate system with its own worldview, glued to the framework at a narrow seam. This is expensive. It is also, sometimes, the only version of the project that is worth doing.
Choosing frameworks like you're choosing a coauthor
The practical takeaway is that framework selection deserves more weight than it usually gets. It is not a technical decision. It is a decision about which worldview you want to inherit, and therefore which product you are structurally capable of building.
The questions worth asking are not the ones that show up in benchmark posts. They are questions like: What does this framework make impossible to think? What does it make obvious? Which of my differentiators lives in its blind spot? If I am still using this in three years, what will my team have become fluent in, and what will they have forgotten how to do?
The answers will not be quantitative. They will feel more like a personality test than a technical evaluation. That is because you are choosing a coauthor, and coauthors are chosen on fit, not on features.
A closing note
At Fewzon we spend an unreasonable amount of time on these choices. Not because we enjoy the meta-work — we would rather be shipping — but because we have inherited enough ill-fitting frameworks in previous jobs to know what the tax looks like on year three. The bill always comes due. The only question is whether you agreed to it on purpose.