How to choose a stack for a solo MVP
When you are building alone, the question is not "what is the best technology." It is "what will let me ship, learn, and change my mind the fastest." Those are different questions, and mixing them up is how solo projects stall out in tooling decisions instead of shipping.
Pick what you already know
A framework you know well will always be faster to ship in than a "better" one you are learning for the first time, at least for the first few months. Save the new framework for a side project with no deadline.
Optimize for deleting code
Early on, you will throw away more code than you keep. Choose tools that make it cheap to delete a feature and try something else: a monolith over microservices, a boring relational database over a trendy one, server-rendered pages over a complex frontend build, until you have a real reason not to.
Only add a piece of infrastructure when it hurts not to have it
Background job queue, caching layer, search index, message broker: each of these is a great addition the day you actually need it, and unnecessary weight every day before that. Add them when a specific, real problem shows up, not because a blog post said you would need them eventually.
A reasonable default
If you have no strong opinion yet, a single well-known web framework (Rails, Laravel, Django or a similar batteries-included option) backed by a plain relational database, deployed as one unit, is a genuinely good default for a solo MVP. It is boring, which for an MVP is a feature.