Posted on 2021-04-06 byVlad Călin
In certain online communities such as Indie Hackers, there is a certain question that a lot of aspiring entrepreneurs with a tech background ask again and again: what is the best tech stack for my next startup venture?
There are a lot of technologies thrown around as answer by different people, all depending on their preference and experience. The answer to this is a subjective one for anybody that actually tries to provide a definite list of technologies. It's all based on their personal preferences and what they feel the most confortable with.
Why is everybody asking this question again and again? If you ask this question in the same community, you'll get different answers from the same people in different days. It all boils down to what somebody is confortable with and moves the fastest with. But there are some other aspects one should consider when choosing their tech stack.
When choosing the tech stack for the next startup (or MVP), a lot of people tend to believe it is a make or break decision. Although it might be in some extremely rare cases where the tech itself is the value proposition, in most cases it really doesn't matter the programming language that was used or the framework.
Code is a powerful tool, no matter the language, and a product can be build with any one of them. Each langauge has its strenghts and weaknesses, but they are usually not strong enough or bring enough differentiation to justify picking one over another.
The single most important thing a startup founder and a software builder should obsess about is speed of development. Being able to push features, fix bugs fast and easily, produce code that is not buggy are crucial for the MVP. Spending too much time building the MVP is not a wise thing, and the less time one spends on it, the better they are able to reach market faster, reach real users and receive that precious feedback that will shape the business.
So, the most important criteria for choosing the programming language and tech stack as a tech founder is to choose whatever you can move the fastest with. The language you have the most experience with, along with the frameworks that help you push code the fastest.
The tech stacks that sometimes are refered as being "boring" are usually the best because they are battle tested, there are a lot of resources and integrations in the open source communities, and they just get the job done.
My personal choice for projects are Python, Django and PostgreSQL because they play well together, they tend to do the job, and I am able to craft software with this plain and simple stack at a very fast rate.
If the purpose of the project is to become a full fledged startup, it is crucial to choose a tech stack that will allow you to grow. And by growth, I don't mean from a performance point of view. The truth is that an application can handle thousands of users with the simplest single node architecture and no fancy setup, no matter the langauge and framework.
By growth, I mean the team size. With more and more users using the product, the amount of work needing to be done will increase. More bugs will surface, more testing will be required, more features will need to be implemented, and all those things will take more and more time as the codebase grows.
At some point, you will need to hire people to help you. One person can write just so much code, and the project will reach a stage where client relations and management, careful architecture of new features will need to be done.
All that new workload will crush a single person trying to do everything, so new people will need to step in.
For developing an application, these people need to be somewhat proficient with the tech stack of your project, or at least be able to get onboarded and become productive relatively fast.
If you use some obscure language that has no relevance in the job market (such as OCaml, Fortran, etc), it will be almost impossible to find people with the required skill set. A lot of investment will be needed for the recruitment and for teaching the new teammates the intricacies of that obscure tech stack. That if you can find them. People will not be willing to step into a career path on which the experience gained will not be relevant for the market and they will get stuck.
The more popular the tech stack, the easier it will be to find talent when the time comes to hire and expand the team.
It's no secret that nowadays, applications need to do a bunch of things. At least the ones that want to have a shot at gaining traction and customers. They need to do some background processing, maybe some data scraping, some integrations with external services, all that good stuff.
It will be inevitable that at some point, there will be multiple computing units running at the same time (or microservices as some people like to call them). When choosing a tech stack, it is important to prepare for the future. For that, choosing a language that is able to do all the things is the best bet for success (and sanity).
The worst place a startup tech founder can end up in is having multiple services, each one of them using different technologies. Then the problem that we talked about in the second part (with not being able to find talent) shows up in this situation too, but in a different form: now you'll need to hire specialized people to develop and maintain a single service each.
The teams will become overly fragmented, collaboration will take a hit, and your team will have a lot of single point of failures: if a single person leaves, the services they were responsible of will suddenly become unmaintained.
At least in the early days of the startup, this problem becomes even more important as the resources are scarce and you can't afford to hire one dev per service. You'll need to build the core team that will handle the whole product as a team.
This way, when the company grows, they will be able to manage their own teams, having the domain and business knowledge they accumulated from the early stages of the startups.
Choosing the right tech stack for a startup or MVP is important, but not for the reasons people usually think of. Most people believe the language itself, or the framework will make or break the product because they don't have the features that the product development requires.
But more than often, it is the wrong judgement.
The most important criteria a tech founder should choose the tech stack by are: how fast they can produce functional high quality code with it (there is no time to dibble with and learn new technologies), how easy it will be later on to scale the team and find talent, and how the ecosystem of the chosen tools looks like: will you need to switch languages and frameworks often or can you choose a single language to handle most of (if not all) areas of your app?