Choosing a tech stack

A tech stack, short for technology stack, is the term used to define a collection of technologies and tools used by an organization.

Picking of a tech stack is a fundamental process of IT operations. It's one of the first choices in a new organization, but it's also going to be reconsidered from time to time. If your organization delivers many projects - an agency for example - you might have a different stack for each; if you do one big thing you will update it once in a while.

Hiring

Software engineers choose stacks out of the best technologies for the job, however for organizations the story is different: hiring will be your main issue.

As hiring great software engineers is hard by itself, you want to have a stack that does not make it harder, or at the very least know beforehand how it will affect hiring. Especially after a certain size, hiring enough engineers will be a constant problem and no matter the money or the time, you will be constantly understaffed.

Assess the available engineers and consultants in your area for the languages, technologies and domains you need. Look at hiring ads in the area to find out who is hiring who and for how much; a neat trick is to check over time to see which ads are staying up. If you're fine with remote work, look at remote hires too, so that you have a complete assessment of your options.

Cost, complexity and productivity

Each technology, generally the division is done over languages, is associated with different salaries and rates. However, a more expensive tool does not mean it's necessarily better.

Today many complex tools are freely available to anyone and more often than not that complexity is unnecessary, if a simpler (and cheaper) technology provides all the answers you need. On the other hand, as your organization or project grows, you will need to move to more complex solutions. In other cases, you might need them straight away.

Productivity also plays an important role: a cheap but unproductive tool might not bring the results you expect, while an expensive technology with high productivity can offset the extra costs.

Here it's important to assess the cost/complexity/productivity triplet and keep in mind the immediate future, rather than just the current situation. Sometimes it's easier to start with something more complicated because moving later will be hard.

Downsides and limits

Each technology has downsides and limits. You want to know about them before choosing, so that you can identify what can become a problem or where you can expect roadblocks.

You can find the salaries on Google, but if you are not technical assessing complexity and productivity is going to be more complicated. There are reviews made by software engineers, however they are often written for other engineers and can be biased in highlighting the pros of a tool and not giving enough space to the downsides, going as far as purposely ignoring the major cons or not mention them at all. The best thing to do here is look for articles that speak about the cons or why a technology turned out to be a problem.

You should also check the official documentation for each, as sometimes the authors specify limits and cons.

Don't fall for perfect: everything has cons that you will have to deal with sooner or later. If you can't find them or something is regarded as having none, take it as a warning. It's likely the case that it's an immature tool that has not reached its limitations or disappointed someone enough to write a blog post about it.

Another thing to consider carefully are over-hyped technologies. You can recognize them because they are all over the place, everyone wants to use them because they're "the future" - and sometimes it may well be the case, but from a business perspective you should use them only if they are necessary and give them time to mature, even more so if you don't have the technical expertise to manage them.

Common concerns

I've found managers, CEOs and founders that need to make a technical choice have some common concerns.

What if a technology dies?

It takes time for a successful solution to die out, and it certainly does not happen overnight: it's a slow process that can take years, if not decades.

Major technologies really never die out, although it may become harder to find engineers for them and it might be counterproductive to use them.

What if I have to rewrite everything?

Rewriting your entire code base can and will happen, but if you follow software engineering good practices, it won't be a problem.

For new organizations it's inevitable, as it's unlikely you already have the resources to handle the complexity you will achieve in a couple of years.

Is it going to be performant enough?

Yes. Unless you need extreme computational power, for things like video processing or cryptography, whatever technologies you'll choose will have the necessary performance.

With modern cloud solutions, you can switch to more powerful servers by pressing a button, literally.

Is it going to be scalable?

Scalability depends on the software architecture and that is in the hands of the engineers, rather than the technologies. With good engineers, definitely.

Modern applications can go a long way before scalability and performance become a problem and by then you should have enough money to deal with the problem.

However, you don't need to deal with it immediately, especially if you are starting small, short on resources or lack technical knowledge. In some cases you need scalability from day one to make a reliable product.

If you have the knowledge and the resources, go for it. Otherwise, keep in mind that you will have to slow down and upgrade your stack at some point.

Hire a consultant

If you're not technical, it's going to be hard making all the right choices. There might be business bits to it, but the difference between this tool or that can be a technical detail that is hard to appreciate without being an engineer and mean a lot, at the same time.

If you don't want to go mad, hire a consultant and let them do it for you. You can use this article as guide to the process and reference to understand whether you are on the right track, but it's far to be a complete guide: that would require a book!

The magic of choosing a tech stack that works it's all in having room for improvement, being aware of the limitations and not over complicating things.