Technology choices matter, but they are not the first architectural decision. If a database, framework or deployment model is selected before the process is understood, the project can quickly start serving its tools instead of the business problem.
I usually begin with the process and data map: who creates data, where it changes, what the source of truth is, which operations are time-critical, what can operate independently and what must survive the failure of one component.
The stack then becomes a consequence of requirements. This reduces accidental dependencies, makes upgrades more predictable and lets architecture be discussed in terms of outcomes: processing time, operating cost, availability, recovery and the ability to evolve.