| A little bit of tough love: You're going about this the wrong way. Build from the problem down to the tech stack, not the tech stack up to the problem. Here are some questions I'd ask in the following order: 1) What is the problem we are trying to solve? 2) At a BUSINESS LEVEL what is our solution? Not we route records through this $DATABASE and $CRUNCH_THEM, but "we enable users to solve $PROBLEM by $GENERAL_SOLUTION_DESCRIPTION" 3) What makes us different from other solutions to $PROBLEM or why is our approach more unique than what currently exists, at the business level? Better idea, better execution, what? 4) What is the market for $SOLUTION to $PROBLEM? How do we know this? How do we sell it? 5) What kind of processing do we need to do? Any serious custom crunching or are we interfacing with a database and moving data back and forth? Can we plug into existing services and leverage them rather than writing our own? i.e. AWS/Azure? 6) What is the best way to deliver this solution to the end user? Mobile? Desktop App? Web App? Some combination of the above? Why? 7) Given $SOLUTION(S) and $CRUNCH needs what's maximizes our chances for success by minimizing the number of moving parts in terms of tech stack? Do we need to do a web app + mobile with limited crunching backend? Do we need a lot of heavy server side crunching with parallelism/concurrency and a robust object model? Let the problem space guide you to the solution rather than starting from a solution and working up to the problem. It'll save you some technical headaches later. |