It seems like these days the requirements are often an underappreciated way to help inform the architecture. Consider basing your selection of tools on whether

It seems like these days the requirements are often an underappreciated way to help inform the architecture. Consider basing your selection of tools on whether they actually help you solve some specific problem or operational goal. Start with the programming language that you are familiar with. You can evaluate in relation to specific problems whether switching to an entirely different system gives you enough specific advantages. So first make a list of the important things the program has to do. Try to think of how specifically you might program it. Is there a component that you can bring in that will help, and if so, how? What would the system look like if you integrated that? Is there another alternative that is easier to integrate or will work better? Sometimes you just can't know until you outline or try multiple solutions. But don't add subsystems just because they seem popular or try to preselect everything before digging into the requirements and starting to analyze how you may implement them. Don't try to figure out the entire program, just start with the most important pieces. Try to get something working, adding every few days or weeks. And for each problem, look at the architecture and tools available. Keep evaluating components and architecture as you go in relation to specific problems or performance/robustness goals. Some of these things you will know ahead of time and of course should try to consider early on. But be careful because many things you think are needed at the beginning turn out to be unimportant or can be eliminated by changes to requirements.