The full set would be something like who the target market is, whether it's a completely internal or completely standalone thing that just happens to be built with web tech, whether it's intended to be offline-capable and whether there's a lot of state involved in the interactive capabilities of most views, should there be the capability to do any kind of concurrent UI things like picture-in-picture video while someone navigates the rest of the screens and changes data frequently, and then the importance/complexity of maintaining a high-level of accessibility.

What I was describing could maybe be conceptualized as multiple applications that serve one larger site. You have the public facing staticly rendered site, built in whichever way, but that ultimately has accessible rendered content on page load and as fast as possible. Then you also have interfaces to the data that is rendered there, which might be completely separate codebases for different purposes.

These could also take place in things like a reporting portal inside a company, where stakeholders need to regularly see static or filterable reports of pre-rendered data, and then you have other internally available apps that different departments can use to manipulate that data in ways that they can easily receive immediate feedback on whether or not it's valid or how it looks etc..