How to decide which tech stack should be used in a business project
Tags: startup, development, architecture
Published: 2021-01-15 23:39:32

Every time you start a new project you have to decide which tech stack you have to use, in this article I’ll not share charts about the most used programming languages on GitHub or the most fast-growing JS framework, I’ll give a different approach based on what I have learned on my skin.

**TL;DR**
- You don’t have to use a new tech stack (unless you have so much money to spend)
- You have to choose a tech stack used by different big tech (LTS)
- You have to look for a tech stack with a community with a strong test and documentation culture

When you ask a developer which is the best technology to use for a project normally they focus the analysis on the performance, the coolness (not the popularity) and the philosophical approach. **All these considerations are fine, but they don’t think about the implications that choices have on budget and timing.**

Of course, the performance is essential, but in my experience, there are just a few bad performance technologies, most of the time there is a bad implementation of the technology. Or is just the wrong technology for your purpose! So if you already have experience with something great don’t go for the super promising new technology.

##Developers love new tech stack but is rarely a good choice

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/yppaxhumqmgjo7kgr4iq.png)

Developers are like children and a new tech stack is like a big gift to unwrap under the Christmas tree, they can’t wait to open it and play with it. This is the only reason why so many young developers are enthusiast to try new tech stack. But trust me is not a good idea to choose a new tech stack for a new complex project. I’ll explain to you why: you will start developing some feature and you are like *“wooooooo this is so fucking cool, it'ss the best tech stack ever! I have never been so fast”*

and then problems begin…

You need to do a simple thing, you maybe try to use your old pattern and it doesn’t work and you say “Ok, it's not the correct way to do it, let me google it”. While your beard grows, after reading all the documentation for the second time, having done a thousand searches, having read all the issues closed and not, looked at if there is a single hint on stack overflow but you only find your own question without a response, you look on the second page of google reusing those keywords that you used days before and can’t find anything.

At this point, you have to start to go deeply into the tech stack and is awesome because you start to understand so many things, but deadlines are near and you are so far away from your goal.

New tech stack has another big problem: Training is more expensive. There aren’t many resources, so you’ll often find yourself doing internal courses using the best of your team to educate the newest. If you have a budget you can afford it.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/ztbq2lovxr4exf9nqhrn.jpeg)

##Used by different Big Tech companies == LTS (long time support)

One of the most painful things is to have a core stack that will no more be developed. I don’t know why but normally developers are not so scared about this, but this is a real problem, not so common for a big project but really common for a lot of dependencies.

I can take an example: Parse was a mobile backend as a service platform originally developed by the provider Parse, Inc. The company was acquired by Facebook in 2013 and the project was shut down in January 2017. The platform was open-sourced but the hosted server was shouted down and it wasn’t anymore an MBaaS.
This is just an example but I think is enough to understand that we can’t base a project on something that is used from only one big Tech company.

Another big problem is to include a library developed by a single developer, or by a group of developers but not used in real projects. IMHO this is one of the biggest problems in the JS ecosystem.

In my experience, I have had to decide to maintain some dependencies but is a really time-consuming choice.
Now when I have to the take a decision if I should or not include that dependency I always make a little analysis by answering me this questions:
1) Who are the developers?
2) Is a private project or a company project?
3) Who is using this?
4) Why there are so many forks?
5) How many contributors are there? Who is actually support this project?
As you can see this information you can easily find in the Github repo insight.

##The community culture

Every programming language has his culture, every framework has is communities.
I love the ruby’s community and of course Rails because there is a really strong tests culture. I realized how important tests are because if you create and share a gem (ruby library) without tests nobody will use it! Finding a JS library with tests is a challenge.

**Test and documentation culture is fundamental, don’t choose a stack if the community don’t have these values**

Share your experience about that, I really hope to be criticized by more experienced people.