How do you pick the right tech stacks?

Choosing the right tech stack is crucial for the success of your software project, but honestly, there is no perfect stack to pick. It's simply that some choices are better than others, and depending on what you need and what you have, you are just deciding to pick the foundations of your project. The choices don't have to be final, as your project's requirements and your team's condition will change. There might be better alternatives, and you should not be afraid to switch. You should feel no pressure about choosing the right stack; you must avoid bad ones.

Making an informed decision can mean the difference between a scalable, efficient application and one that is difficult to maintain and slow. Even though choosing the wrong one is not the end of the world, it makes your project harder to manage and more challenging to pivot. Three key considerations when picking a tech stack are project requirements, team expertise, and community support.

Project Requirements

Your project requirements are the first and foremost consideration when choosing a tech stack. What are you trying to build? A simple static website would have vastly different tech stack requirements compared to a complex, data-intensive application. Be clear about your project's needs and constraints.

I think the tech stack doesn't matter much for the most simple CRUD applications, where you don't expect too much traffic and data-intensive operations. In most cases, in agile software development, you want to iterate as fast as possible, so you must constantly change your code and features. In those situations, avoid low-level programming languages like C/C++ because you don't want to worry about pointer operations and garbage collection when you should be focusing more on the features.

When comparing two or three tech modern tech stacks competing in the same realm, the other two factors might be more critical. If the goal of your project is for you to pick up a framework, go for it. However, if you are in charge of picking the tech stack for your company's next important SaSS project, it's safer to choose something that's been out for a while and is battle-tested because you don't want to find out if something is terrible yourself. Let someone else to test the water for you if your goal is not just to evaluate it, there are new frameworks been made everyday.

Team Expertise

Secondly, consider your team's expertise unless you are building everything yourself. It might be tempting to jump on the bandwagon and pick the latest and the "greatest" technologies. However, if your team is unfamiliar with these technologies, the learning curve could slow development and increase the risk of bugs. Choose a tech stack your team is comfortable with or can learn quickly. This does not mean you should avoid new technologies but balance innovation with practicality. This includes not letting the team's expertise influence you the other way. Let's say your team built an in-house framework that no one else is familiar with; it might be tempting and fine if you choose the same tech stack. However, the risk factor is very high for you to continue on the same track for a new project. You might have people leaving the team, and you might find yourself in an awkward situation where you can't find anybody new who would enjoy working with the tech stack, or it would be limiting to expand upon your framework.

Generally, I would recommend against any in-house solution that someone else has not tested. Similarly, I would not trust an encryption algorithm that is not well-established. It leads to the third consideration: community support is critical for any tech stack you pick. The better the community, the easier it is for you to find help when you run into problems that you need to solve yourself or bring someone else in to solve for you.

Community Support

Lastly, consider the tech stack's community support. A strong community means a wealth of resources, tutorials, and third-party libraries that can speed development. It also means you are more likely to find solutions when encountering problems. Tech stacks with solid community support, like Python or JavaScript, are often a safe bet.

You are also more likely to hire someone who knows your tech stack. I don't think that should be the only criteria when you consider hiring someone, but knowing the tech stack helps reduce their onboarding time, thus costing you less to build the product.

A well-established community also means that it tends to stick around for a while. Even though most developers don't enjoy PHP anymore, it's still the foundation for a large portion of the web. It will likely stick around for more, and if you are required to develop something that will last a while, don't disregard PHP just because no one likes working on it anymore.

Conclusion

In conclusion, picking the right tech stack is a balancing act between project requirements, team expertise, and community support. There is no one-size-fits-all solution, and the best tech stack for your project depends on various factors. Make a careful analysis, consider your options, and choose wisely. Your project's success could depend on it.