Choosing the Right Tech Stack for Your Product

Choosing tech stack

In order to quickly build and optimize software products, developers need a trustworthy and capable foundation to build on: a solid tech stack. That tech stack consists of the layers of programming languages, frameworks, libraries, databases, and other supporting tools to help developers build systems that work reliably.

Giving developers the right tools will help them get their development done faster and with better quality, so selecting the right tech stack is an important decision. You’ll need to consider the two main elements of a stack; the frontend that users see and the backend that supports the functionality of the product.

Choosing tech stack

Tech Stack Choice Isn’t (Just) a Technical Decision

Despite what you may hear, your tech stack choice isn’t a life-or-death decision. To some, these may be fighting words, but the truth is: you can build pretty much the same application in C#, PHP, Ruby Python or Go. The difference between the capabilities of many popular web frameworks is small if you do your research.

The purpose of this blog is not to give you a breakdown into each programming language or framework. It’s aimed to help you from a high-level viewpoint to make a better choice with the options you might have at any given time.

With that out of the way – I’ve met many founders and young entrepreneurs who spend ages trying to get everything right for the product. This is understandable, but sometimes having the best tech stack in the world wouldn’t get you far if your team isn’t fully expert at it and you’re living with a tight budget or a deadline around the corner.

If you ask your developers to pick your tech stack, the decision may well become a popularity contest. Your team will know one set of tools better than another, or prefer one, or want to experiment with a new tool. Those are all valid considerations, but they’re not the only ones.

Tech Stacks Need to Meet Business Needs

In fact, to choose a tech stack, you should start by looking at what the business needs, not what the developers want. Ask yourself these questions:

 

  • What are your business use cases? What is the functionality you need to build? What kind of problem are you solving? A product that demands intensive mathematical computations may need a different tool than a product that’s driven mostly by a complicated user interface.

 

  • Are you working on a product that has to be robust enough to effectively support a large user base? Or are you building a proof-of-concept or prototype? The technology required can be very different. Do you need a tool that will scale to meet future needs? Will you be scaling horizontally, vertically, or both?

 

  • Knowing your users, do you need to take a mobile first approach? Do you need to support iOS and Android? Which of those is your top priority? Is React Native a good option?

 

  • Do you already have a technical stack from other projects? Do you have the funds to bring in new tech or do you need to be cost-conscious and leverage the tools and licenses you’ve already invested in? You’ll want to assess whether you can use the tools you’ve been working with, which may save you time and money. At the same time, you need to be open to adopting new technology that may offer features or other advantages your current stack lacks.

 

  • How will you staff your project? If you’ve got an existing tech team, do you have a budget to train them in new technology if needed? If you’re building a team, what skills are easiest to find? Can you afford experts in the technology you want to use?

 

  • Consider the short term and long term impact of your choice. Some tools may make it harder to maintain your application or extend its functionality. If you develop for one platform, do you need to be open to porting your app to another in the future? Some tools will make that easier, others harder.

 

  • How easy will the stack be for your developers to work with? This isn’t just about their familiarity with the stack and how hard or easy it is to learn; you need to consider how well your development environment and other tools integrate with the language.

 

  • Does the stack meet your security requirements? If you have to work with highly sensitive data, you may not be able to use tools that are only available in the cloud.

 

  • Does the support and licensing meet your needs? Open source communities can be very active, but at the same time, there may not be the level of formal support you want. Read licensing terms carefully to make sure technologies are available for commercial use and whether you are free to modify them. Be aware that support for open source products may go away unexpectedly.

 

  • If you have performance requirements, will the tools you use meet them?

 

  • What is the technology’s reputation? Read reviews to learn from other companies’ experiences. Check stackshare.io to see how many other companies are using the tool you’re considering. Sites like trends.builtwith.com and hotframeworks.com also let you see which tools are popular. You shouldn’t pick your tech stack based on what other companies are doing, but you should consider how you distinguish yourself from your competition and how the tools you pick will support you in that.

 

  • How will the tools you’re considering work with any existing systems you have? Can they easily integrate? Do you have to do any data migration? If so, is there support for that process, and how much time will it take to validate the transition?

 

  • How much will it cost? Many products are free in basic versions, with fees charged for access to additional features, additional capacity, or additional support.

 

  • How well-established is the technology? Choosing brand-new technology can be risky. It’s usually better to look for a stack with a track record of successful use, a large community of developers using it, and with a history of good support. You should also make sure the technology is well documented and has resources to make it easy to learn.

 

  • How easy will it be to test your application? Does it integrate with your testing tools and can you easily tie errors back to specific lines of code?

 

  • What is unique about your requirements and your business? Does this stack offer features that match your special needs?

 

  • How flexible is the stack? Does it enforce a specific development approach and philosophy, or will it allow your team to work the way that’s most effective and efficient for them?

Start Looking At These Popular Tech Stacks

Most companies and projects don’t need to go on an extensive search for esoteric packages to support your developers. You’re likely to find that commonly used tech stacks will work for your team, too.

Frontend

Frontend Technologies

User interface development can be done using straight HTML, CSS, and JavaScript, but developing rich interfaces that let a web page feel like a desktop application is much more easily done using one of many popular JavaScript frameworks.

The most common frameworks used today are Angular and React. Both are supported by major organizations—Angular by Google and React by Facebook—and have large user communities. Vue.js is an emerging option to consider, it’s becoming popular with the JavaScript community because it’s easy to work with and very fast.

Backend tech stack

Backend Technologies

The backend or ‘server-side’ tech can vary much more than what’s used on the frontend, because there are many more layers. The backend includes everything from the operating system to the web server, application server, and database, along with the programming languages and special-purpose libraries. There are several popular combinations of tools forming widely used stacks.

The LAMP stack is built around open source tools: Linux, Apache, MySQL, and PHP. Variations of LAMP include WAMP, which runs on Windows platforms, and MAMP, which runs on the Mac operating system. You can substitute Perl or Python for PHP. LAPP substitutes PostgreSQL for MySQL.

Python/Django and Ruby on Rails are popular server-side web-application frameworks. Both are well suited to rapid development. Ruby on Rails even has its own built-in database, which can simplify development in some situations.

Check out our comparison of these two frameworks

Middleware

The frontend and backend need to communicate, and processes running on the backend need to communicate with each other, as well. They are often integrated with middleware, so choosing middleware is another vital part of picking your tech stack. Django (our web framework of choice) comes bundled with strong middleware layers out of the box.

Middleware can often rely on Java and C# programming languages, along with vendor-supported products such as TIBCO and IBM MQ.

Comprehensive Stacks

Some tech stacks allow you to use the same language on both front end and back end, potentially making it easier to staff your project.

The MEAN stack leverages offers JavaScript-based technology on both front and back ends. It uses MongoDB, Express.js, AngularJS, and Node.js. Because MongoDB is a NoSQL database, it supports applications that use unstructured data better than stacks using a traditional relational database. A variant MEEN substitutes Ember.js for Angular.

.Net, from Microsoft, is an extensive stack that has support for front end, back end, and database access. It works well with C# and VB.NET languages. It’s most commonly used in corporate environments.

Be Willing To Change Your Mind and Your Tech Stack Choice

Don’t pick your tech stack based on what you read online. Nothing that anyone’s written without understanding your business, your users, and your development team can make the decision for you. Use the online information to form some opinions and draw up a shortlist of products to consider, and then test them out—use them to solve a small portion of your big problem. That will give you the insight you need to choose the right tech stack for your team.

You should expect to reconsider your decision in the future, too. Technology changes rapidly, and the right decision for last year’s project may not be the right decision now. Take time to review your technology choices periodically so your dev team can continue to work their magic creating a great product.