#1 - Listen to the project, like really listen (Topic: “Deciding on a tech stack” - 1 of 4)

Whether you are a Junior, Senior, CTO, or someone else working with building awesome digital products, then one of the most important and challenging tasks is to set the right tech stack for a given project. The reason being if you pick the right stack, your project will most likely be a bigger success and amaze the world and your stakeholders. But if you pick the wrong stack, then it can have fatal consequences for the project, it will most likely end up with angry clients, delayed deadlines and much more money spend than initially planned.

So over the next month, I will make a series of four posts here on LinkedIn where I will go through some of my thoughts, processes, and learnings on deciding tech stacks for the projects I have helped produce over the last 10 years. In the first post (this one) I would like to talk about a concept that in my perspective is ultra-important - “Listen to the project, like really listen” in regards to deciding on a tech stack. There are hundreds if not thousands of different technologies and combinations to choose to add to your stack, many of them actually solve the same problems, so how do you pick the right from the wrong? How are you supposed to know what all of them do? Well to start with, no human (I have met) knows all the technologies in-depth enough to make a full pros and cons matrix of them. So this part of setting the stack is about believing in your previous experience and ofc making some research before moving on.

But an even more important thing is, like all other software that you develop, then the bottom line of the outcome of that piece of tech is about solving one or more problems for some user/human somewhere, so one of the single most important things to understand is what problem that you are trying to solve. It might seem super obvious when you read it here, but you wouldn’t believe how many developers I have met that were more focused on “how awesome this framework is” rather than “this new framework just solves this problem to perfection”.

So initial by fully understanding the scope and requirements for the project is a very good start. It’s always a good idea to understand the project's long-term goals to not pick a stack that isn’t flexible or scalable enough to cover the many more release cycles for your stakeholders. At the same time, we don’t want to over-engineer the solution and the stack. So before you set the stack, ensure that you know as much as possible about the project now and in the future.

I often have clients and colleagues that ask me if we should use technology “x” after we had a 5-10 min talk about a new project. Earlier in my career, I was very fast to just jump to a stack conclusion of that very very slim brief. What I have learned is that I have had more success with telling them that I need to understand more of the scope before it makes sense to talk about the stack. I would advise you to do the same thing. The baseline is, to concur and nailing a tech stack is about understanding the problem that you are trying to solve.

Hopefully, my initial thoughts have sparked some thoughts on the initial process of deciding on a tech stack for your next project. If not, then that’s also completely ok, if there is another topic you rather would like me to take a deep dive into, then please don’t hesitate to comment or write a personal message to me aka slide in into my DM. Next week I will write the next post in this series about deciding on a tech stack, where I will focus on the next part of my process which is “#2 Breaking down a tech stack”.

And last but not least, a tip if you don’t really believe in thinking about the challenge you need to solve before picking a tech stack, then put a chestnut in your pocket instead, that is supposed to bring you good luck. This one I learned from my mother-in-law yesterday whilst walking around the lakes of Copenhagen. Have a nice week! 🙌🏻