I’ve been planning on writing a blog on how to choose the right technology stack for web applications for some time now. Why is simple. It’s a decision a lot of companies get wrong. And not just inexperienced start-ups and companies making their first steps towards a digital transformation.
That would be expected. But some of the biggest brands in Europe make major technical, and more often strategic, mistakes when it comes to the choice of tech stack their applications are built on. We know because a significant proportion of our IT outsourcing relationships begin by K&C being brought in to migrate web applications and software built on a tech stack that turns out to have been a mistake.
But that’s not what prompted me to write this blog post now. It’s why I was planning on writing it. At some point.
But I’m writing this now because I’ve just been speaking to an old friend dealing with the fall-out of a wrong tech stack choice.
So, what happened? My friend owns a B2B services company. His company’s website is a simple, static site whose core function is to:
That’s it. Nothing dynamic, technologically challenging or architecturally complex. I hasten to add, K&C had nothing to do with his website. Simple, static sites aren’t our ‘thing’. We build the kind of cloud-based, often data-heavy and technologically more advanced and scalable web applications you’ll find details of in our case studies.
He outsourced the build and maintenance of his website to a company that specialises in that kind of web application. Division of labour is a wonderful thing! He can focus on what he does best – running his business. Not dealing with its website.
He chose WordPress, with a custom-optimised page builder, as his CMS because it’s his marketing team who manage the website. He wanted a set-up that would give the marketing team maximum independence to make changes, updates and add new content without having a technical background.
In summary, the choice of WordPress as a tech stack was based on:
We’re not WordPress developers but it’s well-known as the most ‘accessible’ CMS for a simple, static website designed to serve content. There didn’t seem to be a whole lot that could go wrong.
But, as it turned out, there was still room for error. WordPress sites are traditionally built on good old-fashioned, simple, yet functional, PHP. My buddy’s wasn’t. The company he selected to outsource the build and subsequent maintenance to instead used Twig – a modern template engine for PHP.
Now, there is absolutely nothing wrong with Twig. In the right context. It’s an open-source template engine for PHP with a syntax that originates from the Jinja and Django templates. It optimises code execution, which is important for page speed and general performance when PHP has been used to develop a big, complex website. For example, a significant e-commerce store with a big database, advanced analytics, dynamic content etc.
And his WordPress development company did an exemplary job on the coding, according to the company that subsequently took over to resolve the mess he found himself in. Absolutely no complaints on that front.
So, what was the problem? He doesn’t have a complex site that has to run lots of code-heavy bells and whistles. It is, as mentioned, a very simple, static website. He didn’t need the kind of code execution optimisation Twig offers. And while the code execution was great, he didn’t really need it to be.
He hadn’t requested the kind of web application that needed the benefits Twig brings to the table as a technology. And like any technology, Twig has strengths and weaknesses in different contexts. In his context, the choice’s drawbacks came to the fore:
In short, the tech stack simply didn’t fit the technical needs of the web application, nor its strategic requirements as outlined above. It was an overly complicated solution to a simple problem.
He didn’t actually realise Twig had been used until the time recently came for him to change provider. He thought he had a standard PHP-based WordPress site. He complacently thought what the company was building was so simple, there wasn’t much room for error. And he didn’t do enough due diligence.
The result? He’s now paying (more with time and the distraction than financial outlay) for a rebuild of the same site in simple PHP.
The point to telling this story is not to embarrass my friend but to highlight just how easy it can be to make mistakes when it comes to tech stack choice. Especially when relying on expert advice that may not necessarily always be entirely objective.
In his case, taking his eye off the ball when it came to his website’s tech stack didn’t have far-reaching consequences. Resolving it is an inconvenience.
But just imagine if the mistake had been made in the context of a large, complex, business-critical, enterprise-level web application! That could, and regularly does, cost businesses millions.
Even if the web application you plan to build is as simple as my friend’s, and in most cases, it won’t be, building it with the wrong tech stack is a pain and expense. Care should be taken to avoid the scenario.
Which of course begs the question of what a robust due-diligence technology stack checklist should look like if we want to avoid making, potentially huge, mistakes?
First thing’s first. Before presenting our recommended tech stack checklist to go through diligently when specking-out your next web application, or any kind of software, let’s quickly define what we mean by ‘tech stack’.
The patterns, server resources, software and tools used by developers to create the application’s architecture on both the server/cloud and user-side are also considered part of its tech stack.
An app’s tech stack can be broken down into the technologies used for its:
The choice of front-end technology stack is often influenced by preferences around the back-end, and vice-versa.
The choice of tech stack used to create a web application is not just about its performance, even if choosing the technology and tools that will optimise performance is obviously important.
But a modern web app does not exist in a vacuum. It’s part of a business. Sometimes it is the business. That means while client-side performance-level is very important, it is not a stand-alone consideration. A high level of performance has to be achieved within the context of a tech stack that also answers to commercial considerations and needs.
A good analogy is the process of a car manufacturer’s developing a new commercial model. It doesn’t develop a supercar built from the best of the best components, technology and materials. Doing so would lead to optimal product performance, depending on the priority e.g., acceleration, top speed, control, safety etc.
Developing the optimal car for a balance of speed and handling, with no expense spared on the technology, components and fuel consumption needs would result in an F1 racing car, or ‘supercar’. But commercial car manufacturers don’t design, build and sell F1 racing cars or supercars.
Why? Because such vehicles are not commercially viable for a variety of reasons.
All of which is why none of Volkswagen, Toyota, Mercedes, BMW or Tesla build supercars as commercial models. Instead, they design, manufacture and sell cars with a level of performance that is optimised to also allow for commercially viable running and maintenance costs. And commercial car models also need to offer a good level of safety for the driver and passengers in the event of an accident.
Imagine buying a Volkswagen you intend to be used as a cost-efficient day-to-day run around and discovering your model includes a sophisticated fuel injection system for high-performance sports car acceleration. But you have no need for that kind of acceleration in the day-to-day urban environment your car will be used in. It’s redundant.
And not only is the sophisticated technology unnecessary but if it needs to be replaced, you will have to pay a lot do so. Or you need to expensively replace or reconfigure other components it is connected to or influences.
I know next to nothing about cars, so please don’t pick apart the finer details of the analogy if you do! But hopefully, it illustrates why the choice of tech stack used for a web application is so important.
There’s a huge range of possibilities within any modern tech stack used to build a web application. New programming languages, frameworks, libraries and tools of all kinds are constantly being released. And many of them are excellent, solving technical challenges or improving on existing solutions.
While the software developers, architects, product owners etc., choosing a tech stack can theoretically mix and match, and sometimes do, there are a number of established combinations that are most popular.
Defined tech stacks become popular because they offer a blend of technologies that provide a commercially viable way to build, maintain and iterate on a wide range of apps composed of common functionalities and running on commercially viable infrastructure, in a cost-efficient way. Some customisation of the defined tech stack may be necessary, but the core is based on a set of frequently used combinations.
Organisations often have a preference for sticking as closely as practically possible to a particular tech stack across all of their web applications. Doing so makes it easier to plan, secure and manage the human resource of the specialists that are needed to build, run, maintain and iterate upon them.
If every web app required specialist knowledge of distinct tech stacks made up of different technologies, an impractical number of narrow specialists would need to be available to work on those apps.
As of 2021, the most popular defined tech stacks used in web application development are:
LAMP (Linux, Apache, MySQL, and PHP)
MEAN (MongoDB, Express.js, AngularJS, and Node.js)
MERN (MongoDB, Express.js, React, and Node.js)
Serverless (entirely built on a Cloud, like AWS, the serverless stack abstracts the server-side away. AWS Lambda, and alternatives like Google Cloud and Azure Functions, run code in response to events and automatically manage the computing resources required by that code. Serverless will use technologies from one of the other common tech stacks, minus the server-side).
As we couldn’t possibly adequately address the question of which of these popular tech stacks, or customised variants and extensions of them, would be the best fit for particular web apps, we won’t try.
When does IT Outsourcing work?
(And when doesn’t it?)
But what we can do is provide a checklist of the strategic commercial considerations that you should make sure are not compromised by tech choices based on pure technical performance considerations.
This checklist will also help you avoid your tech stack including components with a shallow or expensive (the two are usually found together) pool of specialists able to work with them.
How narrow is the time frame you have to bring your web app to market? Often, there is commercial pressure to launch an MVP (minimal viable product) in the shortest possible timeframe. That can influence tech stack and mean you choose options which allow for an MVP to be launched ASAP.
If you are building an MVP whose time-to-market is the main priority, the aim is probably to validate there is a market for the app. If and when the MVP provides that validation, the app will be rebuilt on a new tech stack with a longer-term strategy that will take into consideration the other commercial considerations we’ll cover.
But in the short term, the right tech stack for the MVP will be one that you have immediate access to a team to build and launch to the shortest realistic deadline.
An agile development methodology for a web app often also begins with an MVP as its first iteration. But if time-to-market pressures are not quite so severe as in our first scenario, it makes sense to build the MVP with a tech stack that will further iterations will also be made using. Especially if the hope is that the MVP, once validated, can be quickly and effectively scaled.
Scalability can refer to the extension of the functionalities a web app offers on the user end. How many users the app’s infrastructure is able to support at any one time without the risk of outages.
And availability, which is what % of the time the app and its functionalities are accessible by end-users. For example, a banking app’s users rely on it to access their money and execute transactions. The bank will quickly lose customers if its app doesn’t have extremely high availability. This kind of web app can’t have 99% availability. It needs to have 99.99% availability, so its tech stack on the server-side needs to ensure that need is met.
Unless your web app has very specific needs that mean using niche technologies can’t be practically avoided, one of the most important considerations when choosing its tech stack is the depth of the pool of IT specialists that will build, run and iterate on it.
If the pool of specialists who can work with components of the tech stack is shallow, there’s a high chance you will run into issues recruiting or even outsourcing the IT team you will need to build it.
Be careful you don’t fall into the ‘Twig trap’ of our introductory narrative. Initial availability of the specialists you need to build and run the app isn’t enough. Unless the local and international pool of specialists for all your tech stack’s components is deep, you’ll almost certainly run into recruitment or outsourcing problems further down the line.
Shallow pools of specialists in a particular technology inevitably mean they tend to be more expensive than the equivalent expertise-level sourced from deeper pools. A deep pool of specialists in an opensource technology or tool also usually means an active community.
And an active opensource community means a richer resource of knowledge, documentation and support your team is able to access if they encounter difficulties. Which they will.
Be careful to assess how ‘future-proof’ each of your tech stack’s components is. To a large extent, this is an extension of our previous point. Technologies and tools with deep pools of specialists experienced in using them, especially if opensource, usually have a long runway before they will eventually become obsolete.
Every web development technology that is a component of tech stacks in 2021 will eventually become obsolete. That’s tech! But you should be confident that point in time is a long way away.
A technology might still have a relatively deep pool of specialists on the market. But ideally, that pool is one that is getting deeper, rather than one that has already passed its peak and has started a decline. Look at the trends.
Is the volume of job offers for specialists in your tech stack increasing or decreasing? Is the satisfaction rate of developers and other specialists who actively use the technology high?
In short, be confident your web app’s tech stack doesn’t include technologies that will become obsolete and need to be substituted. Or you’ll struggle to find specialists in 5 or 10 years down the line, if the app’s lifecycle is expected to be that long. Especially if these components are integral to multiple dependencies within the app’s architecture.
Finally, it’s possible to judge a tech stack against points 1-4 and still make the wrong choices. The optimal tech stack for a web app is one that not only allows for high-performance levels while maintaining commercial viability. It’s also one that doesn’t overcomplicate your app by adding unnecessary weight and complexity by doing things, or allowing for things, it doesn’t, and will never, need.
That brings us back to our car analogy. If you are buying a vehicle for personal use, you might splash out on a BMW or Mercedes if you can afford it, just because you can and want to enjoy the experience the superior engineering and technology affords. But if you are running a courier service and providing your couriers with the vehicles needed to do their job, it’s unlikely you will choose a fleet of BMWs or Mercedes.
Why? A much cheaper alternative will allow them to do their job just as well. Unless the courier service is positioned as an exclusive, high-end specialist service, it simply wouldn’t make commercial sense.
And we can say the same of a tech stack. Choose the tech stack that will allow your app to do its job well now and in future, without additional fat.
If you go through each component of a proposed tech stack, checking it off against the 5 considerations detailed, you shouldn’t go far wrong. And avoiding going badly off-track in your technology stack choice will save you a lot of money, a lot of time, and a lot of headache down the line.
Deadlines may be looming and the pressure on. But don’t rush your tech stack choice. Get it right first time and your app’s future evolution and growth will be all the smoother, and quicker, in the medium to long-term.
And if you feel you could benefit from some experienced guidance in choosing or confirming the tech stack for your next web app, give us a call. We’d love to help!