Vital questions devs forget to ask when choosing a tech stack
Modern companies rely on underlying technology to help them remain competitive. Without a decent infrastructure in place, it’s hard to compete against the myriad other firms in the sector, all automating vast swathes of their processes.
Choosing a tech stack, therefore, has become a significant consideration for a substantial number of businesses. Everyone is trying to figure out how to put a bunch of disparate technologies together in a way that makes sense.
Unfortunately, there’s no set formula for how to do any of this. Most of the time, the CEO is just guessing at the right approach. It’s not a science. It’s more of an art – and that’s part of the reason it’s so difficult. Some firms spend years developing their technology, only to find an innovation sweeping in, rendering their old approach obsolete.
Are you looking to develop a tech stack for your business? Here are some questions you’ll need to ask in advance to ensure you’re on the right track.
What dependencies are there?
Rarely is technology “standalone.” Mostly, any new system you introduce relies on a network of existing technologies, all of which play a fundamental role in supporting your enterprise.
Take Facebook, for instance. The social media site didn’t come out of nowhere. Instead, engineers built it on top of existing systems, namely servers and the internet. Without those two prior technologies, the world’s second most visited website simply wouldn’t exist.
For business, discussing dependencies is essential. You want to try and figure out whether all of the links in your tech chain are strong. Check whether applications can support each other, otherwise things can go wrong fast. If there are weak points, consult with business IT support to see whether you can replace them with something better.
How much maintenance do your systems require?
You might think you’ve found the perfect tech stack. But if you have to spend vast sums of money maintaining it, it probably isn’t a practical solution for your enterprise. You need something that is going to perform day in, day out if you want your business backend to be a success.
Consult with your vendors about the likely levels of maintenance. Many will assure you that they take care of everything in the background for you, including integrations. Don’t take their word for it. Ask other companies to see how these systems perform in the real world. If there are any online reviews, use them.
Some technologies, like WordPress, do a lot without you having to do any work yourself. Updates are automatic. And the service backs up websites, making it nearly impossible to lose your progress. Other technologies, however, don’t come with as much support, forcing firms to hire internal IT departments to maintain them – a massive hassle.
Typically, the bigger the vendor, the lower the maintenance systems require. SaaS providers almost always manage your applications for you, without any intervention on your behalf. If there’s a problem, you don’t have to delve into the source code. You just send a ticket through an online portal describing the problem and then wait for the vendor to sort it out.
Some technologies require more regular maintenance and updates than others, so that needs to be a factor in your consideration too. Often, these are the systems most at risk of security breaches. Backend or support systems are less vulnerable to hackers usually, and so don’t require the same level of intense attention.
How easy is it to build your systems?
Ideally, it should be relatively easy to build out your systems and get them up and running. For most companies, this process should take less than six months. After that point, you need something barebones in place. If development takes longer than that, there needs to be a good business reason for it.
Third-party packages usually require the least effort from you and your people. Many vendors offer plug-and-play solutions, even for bespoke clients. Often, they’ve developed a basic system which they adapt to your needs. They take care of the entire ecosystem in the background, leaving you with relatively little work to do.
Startups, however, have to develop their systems from scratch. Typically, this means using an ecosystem package. The idea here is to provide programmers in your organization with ready-made solutions they can deploy immediately, instead of having to do all the donkey work. NPM ecosystem packages, for instance, break everything up into blocks that engineers can piece together, according to your needs. There’s no need to program things from the ground up. The fundamental elements are already there.
How early in the life cycle is developer technology?
Early iterations of systems are always a little lacklustre. Mostly, they do the job, but they’re prone to high error rates and regular failure. Take the first iPhone, for instance. It was a game-changing product, but it had its fair share of bugs and feature issues. The second-generation phone improved on that, and the supporting ecosystem, but it was far from perfect. Problems were so bad at times that it threatened Apple’s brand image as the company that provides solutions that “just work.”
Businesses can’t afford to take on too much IT risk. So, where possible, they should adopt mature systems instead of new, experimental ones. The more iterations there have been, the less likely they will experience wholesale failure.
Maturity also brings other benefits. The longer a system has been around, the more features and tools it tends to have. For businesses that need customisation, that’s a good thing. It means that you don’t have to spend hours developing new elements from scratch. You can just plug-and-play using existing solutions.
WordPress, for instance, is one of the most mature website development platforms on the internet. It offers exceptional personalisation options, plus a bunch of ready-made add-ons for practically any website function you can imagine. If none of those fit the bill, users can simply use the system’s simple coding solution to input new HTML as they see fit. It’s incredibly easy to use.
You can also check how widely people in the industry use a system to get a sense of its usefulness and importance—the higher the market penetration, the better the technology, in general.
Some systems are like the Ford pickup of the IT world. They’re everywhere and provide extensive functionality. Others are like a Jeep. They always do the job, but you get a barebones service. Adding to it is difficult. Your business has to decide based on a range of parameters, including the price, feature set, and customisation options.
Who is responsible for the application?
Developer tools are sophisticated systems designed to act a bit like a sandbox, allowing your startup to build whatever it needs to get the job done. For that reason, you want to choose something backed by a company with an excellent brand and reputation.
Fortunately, you have a plethora of options in this regard. Facebook, for instance, backs React. Microsoft is the brains behind the ever-popular .NET. And Swift is the brainchild of Apple.
Corporate backers like this are usually a good thing. Microsoft, for instance, makes a lot of money from .NET, so wants to support the ecosystem as much as it possibly can. Selling developer tools is a lucrative trade, so support from these major organizations tends to be excellent.
If you want, you can choose to minimize risk by using tools supported by a non-profit backer. Organizations who aren’t in it for the money are less likely to pull the plug, even if revenues start plummeting. Open-source systems tend to be better than closed-source, so be wary.
What culture does the tech stack have?
You might think that developer tools are merely pieces of software for the purposes of creating applications. But, it turns out, that each has a rather specific community backing it up. Developers don’t always know how to proceed on a project. For that reason, they will often consult with others in the community to find out the next steps or the best solution for their particular problem. The support culture, therefore, becomes a significant factor in company decision-making. You want a community prepared to invest time in providing the necessary support, even in the absence of immediate economic gain.
.NET developer conferences usually start early in the morning. People in this ecosystem tend to go to bed early and program during the day. Javascript developers have a reputation for staying up all night coding. And so their conferences tend to start mid-morning to give everyone time to get out of bed.
What talent is out there for your tech stack?
A tech stack is only ever as good as the people who support them. IT professionals will usually specialise in specific areas, meaning that mainstream options are generally preferable to esoteric ones. That’s because you need to be able to find people to support your technology, just in case things go wrong.
Look for the availability of people with relevant expertise in different areas. Specific skills may be much rarer than others.