Choosing the tech stack for a project, is a very important decision, that shouldn´t be taken lightly, as it can deeply impact the speed of development, the ability to add new features in the long run, application performance, developer hapiness and more. Ultimately, a very bad technological choice, can make the project to fail, if not in the short term, in the long term.
In this article, I will talk a bit about some factors I consider important, when choosing a tech stack for any project.
Like many things in tech, choosing a tech stack it´s a lot about trade-offs. In most cases, there won´t be a perfect solution and there will be a few “good” solutions. It´s your job as a Software Engineer to evaluate these trade-offs and based on the information you have about the requirements of the project, choose what you believe is best.
Remember, that things change and you can´t predict the future, so don´t stress too much into getting the perfect solution that will solve all the imaginary future problems. Overthinking this, usually results in over engineered solutions, that will lead to their own set of problems down the road.
Let´s get started.
Type and size of the project
The first factor to consider is the type and size of project. It´s a fixed time/scope project like a website or application for a specific client, that have a finitie set of features and a clear deadline, or it´s a more SaaS type of product that will be continuously developed during many years.
Each of this types of projects, might require a very different solution.
For example, if all your project needs to do a simple CRUD like application for a client, with a clear set of features in a short period of time, maybe you could benefit from using a framework that allow you to build these types of applications quickly with minumum amount of custom code and effort.
On the other hand, if you plan to build a product that will have continuous development for years, that could have many developers working on it, and used by millions of users, factors like support and maturity of tech stack, performance and how easy it is to change and to add new features on top, start to have a bigger impact on your technology decisions.
Functional and non functional requirements
One of the most important factors to consider is of course, the technical requirements of your porject, both functional and non functional requirements.
Does your application require a lot of CPU intensive tasks or it´s more memory or IO bound? Storage? Long running background proecesses?
How many users will your application serve every day? What are the performance and SLA requirements?
All this should be considered.
Team skills
Another important factor to consider is the skills of the persons that will work on the project. Maybe this particular project would be a great fit for Golang, but your team only have experience with NodeJS. Does Golang really have an essential feature for your project, or NodeJS would be “good enough”?
This is when other criteria like Deadlines that I will also talk on this article, come into play. As I said in the beginning, choosing a technology stack for a project, it´s a matter of trade-offs and you have to consider all these criteria together, to take the best decision possible.
Maybe you have the time and flexibility in this particular project and it can be used as a way to improve your team skills, by using a language they are less familiar with? But if that´s the case, again think about the consequences of this choice. The development will probably be slower and the code might have lower quality. Can you/your company live with that? Will these new skills be usefull for the team in future projects?.
Deadlines
Many developers don´t like deadlines but it´s fact that in a way or a another, we have to live with them and so they should also be considered when chooising a tech stack for a project. If you have a strict deadline for a project, you should stick to the basics and for example, favor a tech tech stack that you or your team is already familiar with, or maybe make use of a framework that can do most of the code for you.
On the other hand, if you have a more relaxed timeline, maybe it can be a good opportunity to try something new. This doens´t mean you should use the fancy and shiny new Javascript framework that was released last wekk, but something that make sense in the context of that particular project.
Team Growth and hiring market
Imagine you are working on a startup, and you have a product that is really taking traction. Maybe you have received some VC funding and you want to deliver new features a lot faster, and for that you require to double or triple your team size. This is a very common scenario with VC funded startups.
But your project was built in a more niche language, let´s say Crystal. Will you be able to find enough developers with Crystal experience to triple your team in a few months?
A competitor, built a simnilar application, but with NodeJS. In theory, who do you think will be able to grow their teams faster?
I am not saying, that you should only rely on “popular” languages and frameworks. Again, it´s a matter of trade-offs. Maybe your application is so specific that it would have tremendous benefits to be built using a very specific technology that is optimized for that types of applications. For example Erlang, is known by being a great language to build real time systems like messaging applications.
Or maybe you have great internal capacity to train your new developers in a new language and you can attract developers than want to learn new things and get out of their confort zone.
Trade-offs, Trade-offs, Trade-offs …
I would still recommend, if your project is really critical (like the main source of income for your company), to not move too far from the more mainstream languages, unless you have a very compelling reason to do so.
Community and Support
Another important factor to consider is the community and support. More popular languages and frameworks tend to have bigger communities and a lot more available resources, like tutorials, blog posts, stack overflow answers, etc. Using a tech stack with a smaller community and less available resources you might find yourself stuck and have to dive deeper into the code, in case you face any issue.
Of course, all the most popular languages today, were smaller languages once, so … It´s just another factor to take into account.
Maturity and Stability of the Ecosystem
A factor that I think is offten overlooked is the maturity and stability of the ecosystem of a specific tech stack.
This might matter less for smaller or personal projects, but for bigger and more complex enterprise projects, it´s essential. No company wants to be rebuilding all their software every year with the new hot framework. So if your building to last or you are building the foundations for other products to be built on top, you should consider using a more mature, stable and battle tested technology.
Note that stable and mature doens´t mean unsupported and unmaintained. A good example of this is probably PHP. While it´s not a shiny languages anymore, it´s battle tested and actively mantained with a lot of great features being added to the language in every new version.
Tooling, Documentation and developer experience
Thr last point that I would to mention in this article, is related to the tooling, documentation and developer experience.
You should prefer using technologies that have great documentation and tooling and that provide a good developer experience.
Using a technology with poor documentaiton will make it harder and slower to get started and to onboard new developers, and could lead to frustration, when your team face any issue and they don´t know how to solve it.
A bad developer experience, like for example, very slow compilation time, bad IDE/Code Editor support or an extreme complexity to do simple things, can have very damaging impact on your team ability to ship features fast, and can also lead to frustration because of a subpar development process.
Conclusion
There are many many factors, that you have to consider when choosing a tech stack for your project. I tried to talk about a few of them that I consider very important, but I am sure that are others and they can also depend a lot on the context.
You cannot and shouldn´t try to predict the feature and all the imaginary requirements, but you can use of all these factors, and based on the information you have, do the most informed decision possible. Sometimes you will get it right, others might end up being a bit off, but for sure, if you consider all these, you will be a lot closer to success.
Hope this article was helpful, and thanks for reading.
See you.
