Choosing the right tech stack is a crucial decision that may affect the success or the failure of the software development project. Therefore, based on our experience we have prepared a short guide to help you make an informed decision.
Before going into details, we need to bear in mind that choosing the tech stack for a project is not only a question of choosing programming languages, programming platforms, and library sets. The choice also encompasses server components, off-the-shelf software, and different hosting environments such as on-premises infrastructure, private or public cloud. These elements can be used to build a custom solution or as a component in a software integration project.
Of course, the tech stack is also determined by the chosen solution architecture. We can choose a monolith or microservices; decide to build a desktop, web, or mobile app; use only the backend or frontend part—all this will affect our decisions on the tech stack.
Now, let us analyze 10 factors that should be considered before making the final decision on the project tech stack.
#1 Technology stack requirements in the project
The first factor is the tech stack requirements in the software project set up by stakeholders (client, IT department, business owner). First, we need to verify if these requirements are so strict that there is no room for any modifications. People may stick to certain technologies or solutions because they are used to them, even if there are no business or technological reasons why we should use this or that particular programming language or framework. Sometimes, people prefer a particular tech stack because they have the necessary skills or lots of experience in using it. They simply want to stay in their comfort zone.
These are psychological reasons why certain technologies are used and why they are proposed as a project requirement. Yet, questioning these requirements may be beneficial for both sides: for an IT service provider and for a client or their business department. An external IT service provider can give a new perspective and propose a different approach that might be better from the business and technical point of view.
Of course, experience with the technology and psychological factors also play an important role, as you can hardly imagine choosing a technology your team does not like or does not know how to use. Yet we should do our best to not to be limited by these factors and back our choices with strong evidence and facts.
I remember the case of one of our clients whose team was working in a niche technology. They wanted to augment the team to conduct a project. But specialists with the skills required for the project were very hard to find. Despite much effort, the client could not complete the team to start the project. In this situation, we helped them to build a team with more common skills that were easier to find. In the long run, such a team was also much easier to retain.
What is also important is thorough analysis and validation of the project requirements, which is an integral part of the software development process. Nothing can be taken for granted—everything needs to be carefully examined. A well-conducted initial analysis is crucial for a successful final deployment. Skipping or skimping on this stage for whatever reason may lead to serious problems at the later stages of the project.
I believe that this initial analysis should be the golden standard for an IT service provider. If they are able to do it right, they can establish themselves as a trustworthy partner able to deliver a project successfully.
And questioning the technological requirements of the project, however set in stone they might look at first glance, can be beneficial both for the client and the IT service provider.
Read more on bespoke software development:
Azure OpenAI services: potential business use cases
Is ChatGPT dreaming of conquering the world? Generative AI in business
The power of generative AI at your fingertips—Azure OpenAI Service
Business process optimization in the pharmaceutical industry—7 practical use cases
10 reasons you should consider legacy system modernization
Why build a custom e-commerce platform for B2B clients in the manufacturing industry?
How to choose an enterprise software development company—a checklist for CTOs
#2 Matching the tech stack with the solution
The second factor concerns tech criteria. When choosing a tech stack, it is important to match the technologies to the solution type you want to build. Some programming languages or platforms simply work better for specific use cases. We need to consider all pros and cons before deciding what tech stack is the best fit for our project. This should be the backbone of every initial project analysis. We should avoid making technical decisions based purely on non-technical criteria.
This rule also works for off-the-shelf software or components that will be part of our solution. Every piece of software has been designed for a specific use and it is not worth going against what its creator recommends. Of course, we can implement mass integration processes using human workflow engines, as one of our clients wanted to do. But this approach very quickly proved to be inappropriate.
Last but not least, we need to avoid creating technical debt at the beginning of the project. Therefore, only the newest and most stable components with long-term technical support should be chosen for our project.
#3 Availability of tech support
The third factor is the availability of tech support for the tech stack chosen for the project. Here I mean operating systems and our solution’s components. In the case of commercially available software, tech support is standard. Still, we need to calculate its cost. The cost of support and maintenance services might be higher than the cost of purchasing the initial license.
If a chosen component is in the form of free or open-source software, it is good to check if its provider offers tech support. On some projects, tech support provision is strictly required, but even if it is not required, it is worth having.
#4 A clear development roadmap
The fourth factor is avoiding software whose providers do not show a clear development roadmap or do not release new versions and updates regularly. This is especially important for open-source components. This may lead to problems with bug fixing or security issues. If the provider of the software we have decided to use in our solution does not fix bugs regularly or provide security updates, we will need to do it ourselves. Sometimes, this may not be possible because the source code is closed or there are license restrictions. In that case, we may need to create a workaround, which makes the project code more complex and thus more difficult to maintain.
But things may get even more difficult. I remember a situation when the provider simply decided to abandon further development of a component we wanted to use in our solution. This meant that it would soon become obsolete and its integration with new technologies would not be possible. If we had chosen this component, in the future we would have been forced to rebuild the entire solution due to its lack of compatibility. Fortunately, our solution architect spotted the issue in time, and we chose other technology.
#5 The size and market share of the tech stack
The fifth factor is the size and market share of the software we have decided to use in our project. Personally, I would not recommend using local or niche software providers. They might fit into our solution architecture well, but the more popular the software is, the lower the risk that its development will be abandoned, or it will be bought up by a bigger player.
This player may want to merge the software with its own products or even remove it from sale. In both cases, it will be us who will need to pay for adjusting our solution to make changes or for using a new licensing model.
#6 The possible impact of geopolitical events
The sixth factor is geopolitical events. However abstract it may look, such situations do happen more frequently than you might expect. If we chose software from a country with an unstable political situation, we need to calculate the risk. The software provider might limit tech support for their product. Software may also be put on a blacklist by the client or their IT department for security reasons, especially in organizations that gather sensitive data or have strategic importance. In the worst-case scenario, the chosen software might contain malicious code, aiming to steal confidential data, for example.
Sometimes we might even need to check if there are any export restrictions for our client’s country. Such restrictions may limit the number of technologies we can use in our project for this client.
#7 The availability of IT specialists
The seventh factor is the availability of IT specialists with the skillset required on the market. And it is true that much has been written on the topic of growing demand for IT talents. When we look at this in terms of recruiting for a project, however, we need to consider not only the specialists’ availability but also the prospectives for professional development and talent retention.
From my experience I can say that people with unique technology or programming skills are not numerous (like, for example, Kotlin developers), are difficult to find, are expensive to hire, and are often very reluctant to take on new challenges—that is, to change the job.
If during a project we need to augment the development team, their low availability may create a serious obstacle. Therefore, we need to carefully ponder all pros and cons of choosing a niche technology. Maybe other, nontechnical advantages related to IT specialists retention will be more important than the advantages offered by a rare and unique technology.
Even if the chosen technology is very popular, it is good to check if the popularity also means higher availability of IT specialists. High popularity usually results in growing demand for specialists. This means that many companies compete for the same pool of talents, which is always limited. Thus, we can quickly face the situation when we cannot hire any of them because they are literally deluged with job offers. The popularity of a technology is also one of the most important factors that impact IT talent salaries and the entire project budget.
If there are more software projects in our portfolio, it is good to verify if it is possible to exchange IT experts among them and choose the tech stack on this basis. It will be much easier to replace a team member or add a new one, if such a need arises.
#8 Level of popularity among developers
The eighth factor is of a psychological nature. This is whether development team members like or dislike a particular technology that we want to use in our project. And there might be various reasons for that.
Developers might not like such technology because they consider it obsolete and incompatible with current software development trends. As a result, they will be reluctant to use it because of a fear that it may negatively affect their professional development. And this is obvious: in a highly competitive IT market, nobody wants to lag behind working with an obsolete framework or in a programming language that hardly anyone uses.
Some technologies are unpopular because their dependencies force us to use outdated software versions. And this takes us back to what I have already said earlier: Developers are usually very reluctant when it comes to working with an old tech stack.
This reluctance may also result from the fact that some technologies are hard to work with. They are complex, have a steep learning curve, create lots of dependencies, or their documentation is poor or lacking.
Given all this, if we decide to choose a technology that our developers do not like, we need to do it wisely. It is reasonable to include in the budget estimates higher salaries for the team to convince them to overcome their reluctance.
If there are other viable options, we should consider them as well. This psychological factor should not necessarily be the decisive one. Still, in the course of a development or maintenance project, it will certainly become more important than you might have expected at its beginning.
#9 Training and certifications
The ninth factor is access to training and certifications. This is important because it shows that the chosen technology is being developed and is popular. And this makes it easier to find experts with the required skills.
What is also important is that the entry level of the project is lower if there are training materials and courses available. In other words, IT specialists who want to join the project will have a shallower learning curve. For the IT service provider and the client, it will be easier to augment the team too.
Another important aspect is that courses and certifications allow technology experts to meet the formal requirements of the project. In the case of the software company, such certifications will be proof of the experience and skills needed to deliver the project.
#10 Hype around certain technologies
The tenth factor is hype. Just think of blockchain, microservices, or more recently generative AI. If we consider using a technology with lots of hype around it, we need to act with caution. All opinions should be critically verified by our tech team. Some technologies can be considered attractive by IT specialists and decision makers because of the marketing buzz created to promote them.
I think that choosing a technology stack based on hype is very risky. Before making any choice, we need to carefully analyze our project requirements and decide whether using technological novelties makes sense in our context. Sometimes, developers want to work with the newest tech stack and argue in favor of this or that novelty.
On the other hand, companies want to stay ahead of the curve and be considered innovative. Therefore, they decide to use trendy technology because everybody does. And if something is so widely used, it cannot be wrong. In this way social proof replaces strong evidence.
As a result, it becomes harder to deliver such a project, because the chosen technology is very difficult to implement, and we need to find workarounds or pay higher maintenance costs.
In the worst-case scenario, we might be forced to change the tech stack and rebuild the solution. So, we should choose wisely, taking into account technological and business reasons while taking a critical approach to popular beliefs and assumptions not backed by hard evidence.
I recall the hype around microservices a few years ago. During the discussions about a solution’s architecture, proposing other approaches than microservices was treated almost as a heresy. Now that the hype is over, we can clearly see that microservices architecture has its pros and cons and does not always work better than a traditional monolithic approach.
I think this is true about every technology. Each offers benefits but there are always some limitations. In the technology world, there is no panacea that will solve all our problems and make all stakeholders happy. We need to remember this simple truth.
How to choose the right tech stack–takeaways
Of course, none of these factors should be treated as a decisive or predominant reason for choosing a particular technology. As life is full of twists and turns, there can be different and unconventional business scenarios where thinking outside the box is necessary. In other words, all these factors should be considered one by one to ensure that a decision will be taken based on solid reasoning and not mere presumptions.
Therefore, regardless of the approach and technological choice, a detailed analysis before the project starts is a must. The more complex the problem is, the more technological and business experience is required to solve it.
Our ultimate goal is to build a functional solution meeting business requirements. Technological and other project-related choices should be the means to reach the goal and not the goal itself.
