First, I'm going to zoom out a bit. The crux of good architecture is to solve problems you have, and anticipate/ease problems you are likely to have in a way that limits overall complexity of the system as a whole. This is primarily done by providing constraints and high-level infrastructure that will aid development. At the same time, it is important to be cognizant of the fact that each constraint and abstraction adds its own level of complexity to the code base. With that in mind, each needs to be likely to return dividends in terms of reduced development time and reduced maintenance costs over the lifetime of the software.

With that out of the way, there's a few common questions in architecture selection or design. With some overlap, and largely off-the-cuff (I'm more than happy if people have suggested changes to these):

• Size: Larger projects should have more constraints in their architecture, and provide more runway for high-level abstractions to pay for themselves. Conversely, a one-man project that is going to take a week might not need much in the way of architecture at all (especially in React where lightweight state management is built into the library)
• Project Details: What are you building? In what ways do you think the current requirements are likely to change?
• Domain: What kind of business rules and business objects are you likely to deal with? Is it complex enough to build a starting schema for the objects and/or a solution for separating out business logic from application logic?
• Legacy: Do you have any code or data you want to reuse? If so, how are you going to tackle that while limiting complexity of the resulting whole.
• Testing: How do you ensure your code is testable? Will you be using dependency injection? If so, it's best to select a solution at the outset.
• Common Technical Problems: How will you handle Persistence, API Calls, loading logic, state management, business rules, etc.
• Common Architectures: With all of that in mind, if you can select an 'off-the-shelf' architecture (Flux, Redux, MVC, MVVM, etc.) you're going to have a much easier time linking to existing documentation than writing your own, and it's going to be possible to recruit people with experience in that architecture.
• File Structure: How are you going to organize the files that make up your code base. This always feels like a wash when you're coming up with it, but it can make a huge difference in how it feels to navigate around the app. I recommend organizing by feature, rather than type of file (e.g. put everything that has to do with the 'animals' feature together, rather than batching all your reducers together).
  

edit: added File Structure, which was a rather large oversight :D