[dsacco]

There is no "best" tech stack. In fact, this is one of the least important questions you should be asking when starting a software company. In rare cases your choice of tech stack will have a meaningful impact on your business outcome. For example, Whatsapp probably did benefit quite a lot from deploying Erlang. I would argue that if you have to ask this question, it's the wrong question to focus on.

In almost all cases, the tech stack is essentially meaningless. This runs counter to what we frequently want to believe as engineers because there certainly are meaningful technical differences between languages and frameworks. These differences just don't generally translate to meaningful business results.

For example, I am aware of a SaaS company with fewer than five employees total that generates over $3M in revenue annually. The profit margins are mouth watering - total non-payroll expenses are high five figures/low six figures each year. Everything is developed with PHP and MySQL - it would be vilified here, but it's more successful than virtually all the SaaS companies mentioned on HN.

I cannot tell you how many YC companies I have worked with that use Python, Ruby, JavaScript, Go, etc. At this point when I'm on a scoping call with a founder, I can roughly map out when the company was founded +/- a year simply by listening to their technology choices. I have not seen any meaningful difference in whether or not the company ultimately went on to great success based on the tech stack. Instead, I have seen companies go on to great success based on proper identification of real pain points, product-market fit, marketing and ability to execute well while wearing many hats. (But do keep in mind that this is anecdata and subject to usual biases of statistical rigor, or lack thereof).

My advice to you is this: develop your software in whatever language allows you to think more about business decisions and less about technical decisions. Your aim should be to build fast, iterate fast and fail fast. Many engineers who start companies struggle with this because technical decisions are their comfort zone, but your company will succeed or fail based on how well you identify market opportunities and figure out what your users want. If you just happen to be most comfortable in an "academic" language or a really trendy one, go ahead and use it. However, if you're most comfortable in Python, but you fetishize functional programming or React + Node.js because of the Medium posts that pop up on HN, go with Python.

Practically speaking for you specifically - I would first revisit whether or not you actually need a web app and two mobile apps. Could you get away with a minimal web application and choosing only one mobile application to start? Maybe develop in iOS or Android first, observe how your potential customers use the app, address grievances and product a mobile app for the other platform in the next iteration.

As for the actual technical choices - if you know several ways of developing iOS/Android/web applications, go with what is most familiar to you unless you have clear and incontrovertible evidence that one technical choice is clearly superior. If you have to learn a new tech stack to develop one of these, then 1) don't focus on it now, focus on market validation and 2) choose tech stack with the best combination of stability and ease of use to get up to speed with that platform.

Good luck!

[jksmith]

This.... This is about business, getting to market, making money. It's not about programmers' pet interests - those days are long gone. That's why it's important to pick a toolchain that's 1) easy to code, 2) easy to test, and 3) easy to hire for with a reliable expectation of skill level. Unless you're plugged into a small team of very advanced programmers, and this small team is all you'll ever need, you won't be using something like Haskell. Likewise, if you choose a MSFT toolchain, and are hiring blind, you're likely to do a lot of interviewing, because the market is flooded with programmers with this background who claim to be seniors but really aren't, and you can end up with a messy project with lots of tech debt very quickly if you're not careful. One toolchain I've used that does meet those three criteria I mentioned above, therefore letting you get shit done that is closer to being on time, in budget, and correct, is of course golang.

One more point: It's important to understand what parts of your app are capitalizable, and which parts are aren't. The really capitalizable parts are the ones you think bring real competitive value to the market you want to attack - the code that addresses your valuable SME and original ideas. So something to ponder: if you want to also develop a presentation layer, how valuable is it really to develop that layer internally when in the long run that work is not much of an asset, and is a time hole for development? No matter how skilled your team is with the latest js framework I can guarantee you that there's some team of kids out there who are much better with the same framework and can develop your UI at half the price. So create your mockups, define your inputs and outputs, and farm that shit out. Unload the UI headache while in startup mode.