A little bit of tough love:<p>You&#x27;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&#x27;d ask in the following order:<p>1) What is the problem we are trying to solve?<p>2) At a BUSINESS LEVEL what is our solution? Not we route records through this $DATABASE and $CRUNCH_THEM, but &quot;we enable users to solve $PROBLEM by $GENERAL_SOLUTION_DESCRIPTION&quot;<p>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?<p>4) What is the market for $SOLUTION to $PROBLEM? How do we know this? How do we sell it?<p>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&#x2F;Azure?<p>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?<p>7) Given $SOLUTION(S) and $CRUNCH needs what&#x27;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&#x2F;concurrency and a robust object model?<p>Let the problem space guide you to the solution rather than starting from a solution and working up to the problem. It&#x27;ll save you some technical headaches later.