When I was developing a side-project recently called Kushy, I had to tackle this issue. Deciding what server-based language and framework we'd use, as well as the front-end.
I defined what features the Kushy application would have. Then I would research the various options to implement the feature, and see their pros and cons -- particularly at scale. I also researched competitors and what technology they used to solve the problem and why (like Twitter sticking to SQL). Then I launched small-scale experiments using some of the options and testing them out practically (because theory is one thing, diving deeper into docs to find they're garbage is another thing).
Based on my experience with the small-scale experiments, and the research I'd accrued, I'd make a decision.
To give you an example:
We needed a huge database of information, most of it was location based, and much of it was relational. We also needed accurate data, since we'd be dealing with e-commerce and even compliance with local and state governments. This kind of scope led me away from solutions like NoSQL, since they're less accurate and less efficient with relations than a strictly defined SQL database. Although NoSQL may do processes like geolocation more efficiently than SQL, the fact that I might lose any portion of data was unacceptable.
We also needed an API and a frontend for users. I explored using NodeJS as the basis, and frameworks like Express and Passport. Comparing this to how fully-featured Laravel, I ended up going with Laravel instead of Node. It allowed me to more quickly develop what I needed without having to string together my own framework out of several JS libraries (and hope I don't have swiss cheese in my security). I developed a sample API in NodeJS/Express and another in Laravel and quickly fell entranced by the simplicity of the Laravel facades.
I have a whole case study on the project I have to get around to releasing. It details a lot of the decision making behind the stack. But I hope this helps!