You’ve got a potential client that wants to build The Next Big Thing™. Or maybe it’s your Big Idea and you’re hiring the development firm down the street to build it. Maybe you’ve researched every tech stack out there, and you think you know exactly how your new project needs to be built. But what if you’re wrong? Will your technology choices determine the fate of the project? How do you know, before you’re deep into development, whether you’ve made the right choice?

At Objective, we have experience with a genuinely wide variety of different stacks and, as they say, experience is the best teacher. If you’ve ever wondered whether you are making the right choice when choosing the tech stack for a new project, this article is for you. I’ll explain why it’s crucial to make the right choice, and I’ll show you our method for choosing a stack. By reading this article, you will improve your ability to make an appropriate choice in tech stack from day one of any project.

The Problem

Here’s the problem with things these days: there are a million and one options to choose from, new and old, and many of them seem roughly equal:

1. The “Tried and True”: Some tools are older and proven, but people you work with may think those tools are “legacy” and outdated.
2. The “Hot and New”: Other options are new and at the peak of the hype cycle, and they seem awesome, but no one really knows where they’ll be in a few months, let alone a year or two down the road.

Let’s take JavaScript, for example. It’s pretty much ubiquitous. You can’t get away with building a website without it, and it’s now being used for API servers, desktop applications, mobile applications, and more. But there are so many precompilers, transpilers, polyfills, and versions for JavaScript that there’s no way anyone can learn all of them. Some of the tools are temporary—just filling in for language features that will be implemented in all major browsers within a few months. All of this is new to the JavaScript landscape. This movement is definitely for the best, but there are times where using the tried-and-true jQuery is a better option.

Not only do you have options in terms of languages and frameworks, you now have myriad options in terms of application architecture. Will you build a monolith that handles everything from database queries to view generation, or will you listen to the software architecture hype and build out 15 microservices? Will you build your web application using the single page application paradigm, or only use “JavaScript sprinkles” where needed? Depending on the size of your application and its features, one choice may mean failure to launch while the other means long-term success.

While having a plethora of options placed before you may seem daunting, what could be worse is the pressure you feel from developers or management. Management, for example, may push for the tried-and-true C# ASP.NET stack, but your developers want to use Elixir because they are excited about its process-oriented paradigm, and both groups have financial arguments in favor of their choice.

As you can see, and have probably experienced, choosing a tech stack is no easy task. But it’s not just a difficult task because there are multitudinous options, it’s also difficult because the choice of a stack can have long-lasting consequences.

The Cost of Choosing the Wrong Stack

Choosing the wrong tech stack can be costly, in terms of short- and long-term financial cost, opportunity cost, and developer morale. For example, when choosing an unfamiliar (and possibly over-hyped) stack, you may be in for some of the following troubles:

• A new stack will require additional ramp-up time to learn the ins and outs of things.
• Some new tech stacks (e.g. React Native) have overly-frequent update cycles that break existing code and require frequent changes to keep up.
• You may have trouble finding experienced developers when you need them.
• The tech stack may be built in an unsustainable way, and lose funding and support. For example, the company behind RethinkDB shut down, saying they were “ultimately unable to build a sustainable business.”
• You don’t know what you don’t know. The hype may indicate that a new stack will solve all of your problems, and maybe it will, but what new ones will you have to deal with? Inevitably there will be some.

When choosing a “tried-and-true” stack, you may think your woes will be few, but you’re just as likely to run into some of the following issues:

• Code written in some older languages is hard to reason about and costs more money to write and maintain. Think C vs. Rust.
• Waning interest in the languages and or frameworks may mean that it is difficult to find well-supported libraries and modules.
• Lower popularity of the stack may mean difficulty in finding developers that are willing to work on the code for a reasonable price (think Cobol in the banking industry).
• Lower levels of maintenance on the framework/language may mean subtle security issues or bugs persist longer before being fixed.

It may seem like no matter what you do, you’re bound to fail. But there’s hope.

The Benefits of Choosing the Right Stack

Choosing the right stack for your next project can be beneficial to your business in many ways. In fact, where choosing the wrong stack can ruin your project, choosing the right one may mean the success of your project in the short- and long-term. Take a look at the following benefits you may experience when you’ve chosen the right stack:

• The base performance of your application will be solid.
• Your developer morale will be high, which means better code, faster, and you’ll be better able to retain your developers.
• Your application’s codebase will be easy to maintain and, while all software incurs maintenance costs, technical debt will be relatively low, and maintenance updates fairly painless.
• The stack will be well-documented and it will be easy to find ways to solve common problems.

The right stack doesn’t necessarily mean the newest and hottest stack. A tried-and-true stack with a lot of community support can be just as good or better than the newly-trending, corporate-backed stack of the day.

The Solution

Now that you know the possible dangers of choosing the wrong stack and benefits of choosing the right stack, let me show you how you can make an appropriate decision each and every time. Don’t be mistaken; even if you’ve made the perfect choice in tech stack, there may be bumps along the way, but by following these guidelines, you’ll be able to select a tech stack that enables your project to succeed.

1. Feature Requirements

First and foremost, it’s important to know and thoroughly understand the requirements of your project. Do you need pseudo-realtime functionality, such as with a chat application? You’ll want to use a tech stack that is good at concurrency, such as Elixir/Phoenix, Node, or Go. Or do you just need a simple blogging platform (WordPress) or a robust content management system (Drupal)? Is your client-side UI full of complex interactions? Then React or Elm may be good front-end stacks. Knowing your planned feature set can at least narrow the set of suitable options.

2. Short-Term Goals

Second, it’s important to understand the short-term goals of your project. In an ideal world, all projects would be built perfectly from the beginning so that they could withstand the sands of time, but often the project’s short-term goals demand sacrifices on long-term ideals. For example, you may be interested in vetting an idea, or perhaps your idea is already vetted and you’re ready to build a highly-scalable, robust version of the application. Or maybe time to market is critical for one project, but less important for another. When you’re building on a short timeline or want to limit costs as much as possible, it’s okay to sacrifice on scalability, robustness, or even developer happiness, as long as you recognize the technical debt that this incurs. You may want to limit using this kind of low-cost approach to a codebase that you are 100% willing to throw away once the idea is validated.

3. Developer Happiness and Availability

Another thing you’ll want to look at is whether or not there are developers that are willing and able to work within your chosen tech stack. If you choose the preferred tech stack of 1970, you’ll be hard-pressed to find many people who know how to use it, and if they do, they’ll charge a premium. So choose a stack that has a vibrant community of developers. That way if you decide to onboard new developers to work on your app, you’ll have a decent pool to choose from. It’s also somewhat important to choose a stack that developers are excited about, or at least are happy to work in. You may be able to find a handful of people in the US who are happy to work with Perl, but the majority of developers nowadays would run away from it. It’s a lot more exciting for many developers to see job postings that allow them to work on at least one thing that’s up-and-coming, even if the rest is pretty run-of-the-mill.

4. Risk Aversion vs. Need for Special Features

The last thing you’ll want to consider is your own (or your business’s) aversion to risk versus the project’s need for special features or functionality. If your company could lose millions of dollars because of a missed transaction, or your application could cause human suffering or death, it goes without saying that you should choose the tried-and-true. If, however, your company is able to absorb a few setbacks and needs the cutting edge technology of the day, it may be appropriate to use a newer (even hyped) stack that allows you to get the features you need at a lower cost of development. It may also be possible to compromise and get a good mix of tried-and-true with newer functionality by choosing something like Elixir, which is built on the Erlang VM (BEAM). You get the benefit of a well-tested VM and the perks of a well-designed, new language.

Methodology and Examples

It may help to go through a couple of examples to get a better idea of how you might think about the aspects described above in relation to an actual project and actual tech stacks.

The following is an example of how we might go about choosing a stack for a potential client:

First, we compile information about the project’s and client’s needs.

Needs:

• Be able to manage a large amount of content
• Content must be available in multiple languages
• Must be able to expose an API for special content
• Content comes in a variety of formats (video, imagery, text content) and needs to be displayed in a variety of ways
• Must last 5+ years
• Must support up to 1 request per second

Next, come up with a list of viable technologies. This list will be different, depending on what’s available at the time (new technologies become available every day!) and where your developers’ expertise lies.

Viable technologies:

• Drupal
• WordPress

I’ve excluded a variety of other tech stacks for this exercise because at Objective we view these two frameworks as the most viable for this kind of project. At a .NET shop, Umbraco could be a framework worth adding. While we do a lot of Rails, locomotive has various issues that make it inappropriate.

Rate the tech against the needs, and against risk and developer metrics:

	Lots of Content	I18N	API	Content Types	Developer Happiness	Developer Availability	Total
Drupal	10	9	7	10	6	5	47/60
WordPress	10	3	3	5	5	10	36/60

 

It is clear that, at least out of the two technologies above, and based on these scores, Drupal is the winner. It’s most likely the tool we would choose for a project of the given requirements, and we have chosen it many times in the past, even though it’s not our favorite tool. You could also add more pieces to the rating chart, such as maintainability and scalability, but they are deemed less important for this size of project.

Note that this kind of grading pattern will always be arbitrary. There isn’t a tech stack scores cheat sheet (that I know of), but you or your developers will need to attempt to be as objective as possible when coming up with scores for each column. A little bit of bias can act in your favor in this case. I tend to grade Drupal higher, for example, because I know it better than WordPress, and the fact that I know it better means I’ll be better and faster at developing web sites with it. If WordPress comes out on top, bias withstanding, then I’ll know it really is the way to go.

Here’s another example, this time focused on choosing a software architecture paradigm:

Needs and Client Parameters:

• Realtime updates of content across devices and users
• Social Media login and integrations
• Complex UI with a lot of interactions for web and mobile
• Validated concept with potentially thousands of users per hour

Viable Architecture Patterns:

• Monolithic back-end, Single Page App front-end
• Monolithic back-end, JavaScript sprinkles on front-end
• Microservices back-end, Single Page App front-end

Ratings

	Handles Complex Application Features	Handles Complex UI	Scalability	Maintainability	Simplicity of Code/Design	Total
Monolith + SPA	10	10	8	8	8	44/50
Monolith + jQuery	10	5	8	5	9	38/50
Microservices + SPA	10	10	10	8	5	43/50

 

It’s a close call between the monolith and microservices architectures on this one, but it’s at least obvious that the single page app paradigm is the way to go. You’d probably have to dig a bit deeper at this point to determine if a monolith would really be better than a host of microservices. The simpler the application is, the more I would lean toward a monolith. While microservices are hyped a lot nowadays and there are strong arguments in favor of using the paradigm, they add a lot of complexity to the architecture of an application.

Things to Watch Out For

When you’re deciding on a technology for your future project, there are a few things you should watch out for:

• Don’t believe overly hyperbolic articles about certain technologies dying off, at least at first. Ruby on Rails, for example, may be waning in popularity, but it could still be the best choice for the job, assuming your developers have expertise with it and your project doesn’t need high performance out of the gate.
• Don’t believe all the hype about new technologies. New technologies are great. They push the industry forward and bring efficiencies to development. But they are often immature and can cost your project significantly. They may solve one problem, but create 10 others, and its hard to know if all your needs can be met in the early days of a new tech stack. Etsy, for example, jumped on the MongoDB bandwagon, only to regret it later.
• Don’t ignore developers’ opinions, but do your research, too. Developers often want to experiment with newer technologies, or are just sick of what they’ve been using for the last 5 years. It’s important to listen to your developers, but do your research and make sure the technology they want to use is appropriate for your project.
• Don’t follow best practices blindly. It’s good to follow best practices, but when doing so could mean incurring a lot of extra development time or cost, question whether it’s necessary. For example, using AWS’s Multi-AZ RDS deployment is definitely best practice, but it’s probably not necessary when you have 2 users. Use the cheaper, easier path until you have a validated need to step things up. That said, don’t make it too difficult to upgrade if you think you’ll have the need to do so soon. If you know you’re going to have to support 5000 concurrent users in two months from now, don’t build your application in a way that won’t scale.
• Avoid WordPress unless you’re building a blog. WordPress is an awesome tool that supports millions of websites. You can do a ton with it, including eCommerce, blogging, and content management. But if you want to build a web application that has more than just content management, or your content management needs are fairly complex, then steer clear. It will save you money (and many headaches) in the long run to use a more robust tool.
• Use React Native for mobile applications. In our experience, React Native is the most economically sound, robust tool to use on mobile projects 99% of the time. Most mobile applications aren’t complex enough to warrant a pure native codebase, and with React Native you get the added benefit of being able to write code one time for two platforms (iOS and Android). It’s also proven much better in terms of maintainability and performance when comparing it to PhoneGap or Ionic. It’s pretty much a no-brainer for us now.
• Don’t be an early adopter. When it comes to projects that are more than just prototypes, it’s best to use a technology that has been around the block a few times. There are definitely cases where a new technology is good enough that it makes sense to use it despite its immaturity, but in most cases, you’ll pay for the privilege of being an early adopter.

Conclusion

To recap, to help you choose an appropriate tech stack, measure your options against the following:

1. Feature requirements and project assumptions
2. Short-term goals (e.g. time to market, prototype, robustness)
3. Developer happiness and availability
4. Risk aversion vs. special features

When choosing between the “tried-and-true” or the “hot-and-new” on your next project, being methodical about your tech stack choice will not only save you time and money, it may save your business.

If you have questions or comments, please contact Dan at dan [at] objectiveinc [dot] com.