The best tech stack when starting a startup is one you don't have to learn.
There's a million things you learn when starting a company. Don't make yourself learn an entirely new tech stack on top of everything else. This advice means you'll be using whatever you've used in the past which might not be the sexiest or newest technology, but your users won't care. Your users want a working product. Choose the stack that will result in a working product the quickest.
Refactor and migrate to a better stack later, if necessary. (It rarely is)
For me, that meant deploying to Elastic Beanstalk (I know, boring, no one talks about it, but it works!) and using Mongo because I was already comfortable with it. It also meant not using React, at first. This was the right answer for me, but might be the wrong answer for you! Build your app on the technology you know.
That's true if you're optimizing for start-up success. The odds of a startup succeeding are pretty low and mostly tech is not the cause of failures though. When people learn a new stack for a startup they're optimizing for the startup failing, so they can still derive some value out of the failure.
This just comes down to a napkin calculation of expected value of building a startup given P(success). If your startup is looking like a real business out of the gate, using the simple stack you know is the way to go, and if it's more of a hobby project that you'd like to monetize eventually, learn something new.
This lines up with how I make tech stack decisions for my own projects. But I think it's not always obvious going into something if it's going to end up being a money-making endeavor or just an educational project in the end, so I'll fall somewhere in between.
What makes the most sense to be is to be really selective about what new technologies to use, and try to really learn ~one thing per project. E.g. my current project is a small search engine, and I've spent a lot of time exploring / figuring out how to use LLM Embedding models and vector indices for search relevance (vs. falling back on using ElasticSearch the same way we use it at work), but I'm using tools that are familiar to me for the UI/db/infrastructure.
If anyone tells you different you can take stacks like Beanstalk VERY FAR. Probbably way further than you want to. We just moved our highest TPS (Transactions per second) and OPS (Objects Per Second) service off of beanstalk after 7 years. At peak this service was serving around 1.1M TPS and around 8M OPS with peaks up to 3M TPS and 14M OPS. It was horizontally scaled and run by about .25 engineers. That was actually the main problem. That and the company got real good at running ECS. Our services are all golang so beanstalk eventually was getting in the way, and one of our last major issues had to do with nginx proxy on bean stalk not keeping up with our go service. There's several other edge cases with Beanstalk like how to do health checks right, and speed of deploys esp when they get wedged. But if you know it you can, as we found, go very far with it, powering a core feature of a very large web property (check my bio).
Am I happy we moved off, yes. Was I impressed how big we took a very simple "starter" setup, also yes. Again one of the biggest reasons was that all of our competence in the company was no longer on beanstalk but on ECS where we had solved the issues we had with it with more complex setups more in our control. If I were starting again would I use Beanstalk? no not me personally but when we started ecs didn't exist and beanstalk was better than bare EC2. now I know and am comfortable with ECS. Did it help the company? very much so, we leveraged the heck out of Beanstalk to scale the company horizontally and vertically.
For my 12 year side project, I recently moved from Elastic Beanstalk after 6-7 years to Platform.sh, because "it just works" even more so and it was way easier to debug (EB just says "error in step 18_install_yarn" or something).
I use Symfony (Php) and have not used a full SPA after I retired AngularJS (v1) like 10 years ago. What people now call server side rendering (SSR) is just how Symfony works with its regular Twig templating language (heavily inspired by Django's templating language).
As I gained more experience, I rewrote it. Once from vanilla PHP to Laravel, then later to Symfony.
But maybe Symfony would be something like Linux Debian, has all the building blocks, it's modern but stable and well documented. Laravel is like Linux Ubuntu, it bases many things on Debian, but adds many things to make stuff a bit easier for the user. It's "shinier" and it has better marketing. You can add Debian stuff to Ubuntu, but you can't necessarily add Ubuntu stuff to Debian.
Symfony is more modular, you can add the components to any PHP project. Whereas Laravel uses many Symfony components and adds some syntactic sugar, but once you go into Laravel, it's difficult to stray away too far from the "Laravel way". Laravel uses many Symfony components, but Symfony can't easily use Laravel components.
Self-hosted Wordpress would maybe be comparable to a rooted Android phone. It has a very specific use case (for Wordpress it's fundamentally a Content Management System). You can add all sorts of plugins and additions. But it's also easy to accidentally break something. And once you added too many things, it might be difficult to update without breaking many things.
In the end, they're all Linux based, but living in very different ecosystems (just as Symfony, Laravel and Wordpress are PHP-based).
In programming terms, Symfony might be similar to Django (Python) or Spring Boot (Java), whereas Laravel is "cousins" with Ruby on Rails.
Server side rendering of React applications doesn't just refer to the fact that it's generated on the server like you do with PHP.
The main difference is that there are IDs that allow the client side code to seamlessly attach event handlers (this is called hydration) to the DOM - and that there is no difference between server and client side code.
In your case, you'd have to do that manually - a huge difference (speaking as someone who used to do that with jQuery).
ElasticBeanstalk is wonderful. Each to his own but for me it was the answer to the question "I agree Kubernetes is overkill for me .. but then what should I use?".
I certainly didn't want to be manually creating instances, installing Java / Node / Docker, starting / stopping services and doing deploys manually because that's also annoying work :) Elastic Beanstalk + the Github actions deploy plugin is dead simple and just works.
The best tech stack when starting a startup is one you don't have to learn.
There's a million things you learn when starting a company. Don't make yourself learn an entirely new tech stack on top of everything else. This advice means you'll be using whatever you've used in the past which might not be the sexiest or newest technology, but your users won't care. Your users want a working product. Choose the stack that will result in a working product the quickest.
Refactor and migrate to a better stack later, if necessary. (It rarely is)
For me, that meant deploying to Elastic Beanstalk (I know, boring, no one talks about it, but it works!) and using Mongo because I was already comfortable with it. It also meant not using React, at first. This was the right answer for me, but might be the wrong answer for you! Build your app on the technology you know.