> What is the tech stack you'd chose for your startup Whatever you can build your mvp and iterate fastest in. Use whatever source control you've used most oft

> What is the tech stack you'd chose for your startup Whatever you can build your mvp and iterate fastest in. Use whatever source control you've used most often and are most proficient in - if that's CVS-RCS, use it anyway - you can always change to git when you get a second dev. Do not even consider Kubernates unless you've used it so much you've forgotten how to configure a regular VM. Do not learn a new database. Use whatever relational db you're most familiar with, or choose MySQL (or a variant). You won't need specialised key/value stores or time series databases until you scale past what a big MySQL/Maria/Aurora instance can handle, and you'll have learnt a _lot_ about your problem space by the that'll give you a real understanding of what data storage/query problems you have. Pick a service and frontend framework you're familiar and experienced in and which has a big enough user base to provide decent support. Ruby on Rails, WordPress/PHP, Django/Python, whatever the relevant Microsoft equivalents are. DO NOT decide the first thing you need to do is write your own framework. That is _never_ the right answer. It is totally not true that "everybody else is an idiot". Those frameworks are familiar because they work - they solve enough of the common problems without making the uncommon parts of your project too much harder than doing it another way. Throw away everything you don't need to get to mvp. You almost certainly don't need GraphQL or caching or service metrics or messengers or bug/project management software to get to mvp. All that can wait until after your second dev and after you've sat potential customers in front of your mvp. Probably until after you've sold to your first 10 or 50 customers. Bug reports in your email inbox work just fine until they don't, wait until they don't before you spend time solving that problem. Just build something and ship it. It _really_ doesn't matter what you wrote it in, it's gonna be rewritten anyway if it succeeds. Many times. Proving someone will actually pay for it is a way more valuable use of your time at the beginning than carefully evaluating the advantages and disadvantages of Go vs Rust when you never used either in anger. A "startup" is usually about building a dog and pony show about how you can solve a problem for a group of people and sell the solution to them - in a way where the size of the group and the price they're willing to pay and a plausible conversion rate makes you a unicorn/decacorn/whatever-we're-calling-it-now. You borrow or fake as much of it as you can. Customers care about you solving a problem for them, not "what your tech stack is". Investors care about customers and how much they'll pay you and how many other people have their problem, not "what your tech stack is". Note: Some of that advice will be "obviously wrong" to you because there's details of your idea you haven't shared. If you're doing computationally expensive or data intensive work, by advice about Kubernates or databases probably don't apply. But you'll know if that applies. Do not fall into the trap of thinking "but I might need a globally distributed shared KV store when I get to 1 billion concurrent users!" when you have zero users, and no clear path to even getting your first 10 or 100 users.