Example decisions are: MySQL vs Postgres, GitLab vs GitHub, Ubuntu vs RedHat
An important aspect is the cost or ease of switching to something else later on - the impact of the decision itself. Switching out your hosted git provider is probably easy, maybe a day of downtime. Switching out databases once you have users on the system would be a major project, maybe 3-6 months. Changing out web frameworks in the example SaaS could be an entire re-write.
If you need to present your findings to some management layer to get them onboard then you may want to get a sense of what they're thinking (i.e. does someone really like XYZ?) so you can focus efforts appropriately. Gathering info on non-functional aspects (cost, support, license model, etc.) will go a long way towards them evaluating the decision if they are non technical.
Generally I find thinks like this are chosen depending on:
1. What other products are in use in your org / team 2. What is the general direction of travel for products in your org/team 3. What is the cost to the org for any licenses / supported versions you want to implement 4. What backhanders / perks / relationships with friends are involved with the management / purchasing team
If you haven't built anything yet, I'd strongly recommend you start building with something you have knowledge of that is commonly and widely adopted in the industry and then refactor as you find you have issues or particular requirements.
Try to be specific with your use cases. Don't write pro of a mysql "Can be used on any shared PHP hosting" if you know you are going to have complex deploys in AWS.
At the end it should be fairly obvious just looking at the document.