Anyone can recommend an arbitrary tech stack. It’s easy. You just pluck random technologies you have heard of out of the air and announce with certainty that’s the tech stack you should use…bonus points if you mention what’s currently fashionable.
However, generally speaking, “What tech stack do I use?” is the wrong question. The tech stack you choose to use should be the answer you come to by asking the right questions.
The right tech stack is a balance. Here’s what you should be considering when choosing a tech stack.
Always start with what is the simplest solution you can possibly get away with. Generally, software is expensive and difficult to build, and despite what the LinkedIn oracles say about generative AI; this is unlikely to change anytime soon.
It’s an open secret that even excellent programmers can write awful code. Why make it any harder than it needs to be?
Whatever code you write will invariably become complex, so keep it as simple as you can for as long as you can.
For (most) products to be successful in the marketplace, you must be able to rapidly adapt them and change them based on user feedback. Even if you don’t need to compete in a marketplace, your product requirements will change over time; PRODUCT REQUIREMENTS ALWAYS CHANGE.
Whatever tech stack you choose, you must be able to quickly and easily adapt to these changes as they come up. If you create something that cannot be adapted easily, it will likely either fall behind the market or become riddled with technical debt.
A good measuring stick for this is how often you can deploy changes to a product. Being able to deploy software updates throughout the working day without breaking anything would suggest a product is adaptable. Not being able to deploy for fear of breaking something would suggest it is not very adaptable.
You want it to be possible to scale your software. Currently, it might only be 5000 lines in the code; in the future, it could be 200 times that. Likewise, you may only have 50 users now, but if successful, you will likely have many more in one day. You must make sure that your tech stack does not get in the way of scaling.
Question: What happens if this code base grows substantially, and what happens if your user base explodes? Can the proposed tech stack handle this?
Developers really like to invent their own way of doing things. It can make it particularly difficult when it comes to building software that lasts more than a couple of years!
Frameworks and services that have clearly defined best practices can be advantageous in this regard, as they give a clear way of working that any developer working on it can follow.
Take AWS & Azure, for example. They have clearly defined best practices and offer training pathways to ensure a developer knows when and how to apply these techniques. This is invariable better than just letting developers invent their own ways of doing things.
However, this is assuming that you can confirm the best practices are actually followed.
Security & data privacy are of the utmost importance. Gone are the days when you could sling together web-based SaaS and fill it with data that identifies users but does not take security seriously. There are very real consequences for data leaks. As such, any tech stack must meet the relevant regulatory requirements. You wouldn’t be the first to scrap a whole software project nearing completion because of a regulatory requirement that was not planned for from the outset.
And before you say, “There’s no sensitive data on my website,” remember that if your website has a contact form, and the messages sent from that form are intercepted in the UK, that’s a reportable data leak.
Most software will be bound by regulatory requirements, even if you are currently unaware of them. Find out what they are and take it into account when planning the tech stack.
You need to be able to implement the tech stack you choose. It’s one thing for somebody to tell you what tech stack to use. You have to be able to follow through on it. You have to be comfortable working on it, and you need to be able to secure development resources to build it.
Costs can be a big factor in feasibility. So remember that in certain technologies, the human resources required to build is higher. You could, for example, potentially build something in PHP for 2/3 of the price. You could build something in React due to the staffing costs of these technologies.
There are plenty of people who will tell you with certainty the best tech stack is ‘x.’
However, everyone has their own biases; developers, online communities, universities, business advisors - they will all have their own opinions fuelled by their own self-interest. At the end of the day, everyone tends their own garden.
The reality is that there is not one size fits all ‘best tech stack,’ and you should be wary of those that suggest there is.
Remember, The best tech stack for you is always the balance of many considerations. It is not a one-size-fits-all answer.
Also published here.