How do companies decide which backend framework to use?

A lot comes down to what the team already knows. If your developers work mostly in Java, Spring Boot may be a comfortable choice. A team using TypeScript across its stack might look at NestJS. Neither is automatically better for every project.

Introducing a new language or framework means training people and getting comfortable debugging and operating it. That cost can outweigh a feature that looks attractive on paper, especially if several options would do the job.

Start with the problem, then look at the framework. Does it have the libraries and tooling the project needs? Can it integrate with a library the business depends on? Sometimes that dependency narrows the language and framework choices before anyone compares the frameworks themselves.

Speed of development can matter as well. For a prototype, a team may favor a framework that lets them build quickly with skills they already have. Laravel, for example, includes a lot of built-in functionality for PHP development.

Think beyond the first release. Can the company hire developers who know the language, and will the framework likely be supported for years? A less fashionable choice can be perfectly sensible if the team can maintain it and find people to work on it.

Migrations are expensive, so a team needs a reason stronger than a newer framework being appealing. Requirements might have changed, the existing system may have accumulated technical debt, or the company may struggle to hire and maintain it.

That doesn't mean the original choice was a mistake. It may have helped the team ship quickly, then become less suitable as the product and organization changed. The cost and risk of moving still have to be weighed against the problems a migration would solve.