How to choose your tech stack

When starting a new project or making a big shift in your current product it is difficult to decide which tech stack to use. On the one hand, you should to choose the best tech stack for your specific product. On the other hand, you should be flexible enough that if the market and technology landscape changes during the lifetime of your product you wont end up having to run a major stack shift again.

This is always easier said than done. This article is meant to give a list of points to think through if you have not gone through this process before. If you have, use this article as a refresher, or to highlight points you may have missed before. Here are a few general questions to ask yourself and your team.

1. What is the product?

2. What is your vision?

3. What is your budget?

4. What is the existing tech stack of your team?

5. What is the existing tech stack of the team you are going to work with?

6. What is the timeline?

The answers to these questions will give you a starting point to build upon and help you choose the best tech stack for your next product. It is important to not be afraid of experimenting with new technology, and to learn from your mistakes. Even if you consider all the options There is no guarantee that you will make the best choice.

Let us take a look at each one of these six questions in more detail.

Product

Think about your current or planned product. What problems does it solve? There are languages and libraries for languages that are better suited for specific tasks. For example - Python is widely known to be good for machine learning, and there are large number of tools and libraries geared specifically for that.

On the other hand - Javascript is really well suited for web development. Frameworks such as React were built specifically to handle user interaction through complex web apps.

Thinking about what your product does is one of the easiest places to start when considering your tech stack. Depending on your product, you can quickly eliminate the majority of choices out there and focus on the remaining few.

Vision

Where do you want your product to go in the next few months? In the next year? If you are looking to stay small - there is no need to provision k8 clusters or setup a complicated server infrastructure. Avoid the trap of over-engineering or solving for a problem that you dont currently have. If you need to scale, or have a large user base already, a resilient server infrastructure is a valid option you need to consider.

Think of the team sizes that will be interacting with your product internally. It is easier for a handful of developers to build and maintain a product. You need better workflows and tooling when you have a large number of people all working concurrently on the product.

Budget

There are tools that span all spectrums of a budget. Signup for the tools that are the right fit for your current budget. If you need to build a sales pipeline for two sales people it does not make financial sense to dump money into salesforce when something like Pipedrive will produce the same results. This comes back to not engineering for a problem that you do not have yet.

Existing Tech Stack

What tools and languages are you currently using? How do they play into this upcoming project? If your existing stack is Rails it will be difficult to migrate to a JavaScript and React architecture if all you are doing is a small project then it would be to build a new project with Rails.

Think about how different platforms will work together, and what integrations you need to make between different platforms. Think how this will impact your ability to solve your problem, and also if you have vendors or API integrations - how this will affect current users.

Team Knowledge

Consider your core team knowledge levels. If your team has been PHP developers for years, and you suddenly want them to build a product in Javascript using React, you are going to run into some issues. I am not saying that it cannot be done, or that people cannot learn a new skill.

Consider the cost involved with learning a new language or platform. Think of both the financial and time impact. Ramping up to a new technology will take additional time. It takes time to both understand the language, and to understand how to think in the framework and how to setup workflows that match this.

Timeline

Most teams should ship products on an MVP timeline. The sooner you can have internal teams or customers using a product, the sooner you can validate your idea with the market or with the team and start to understand their workflows. If you are expecting to launch something within the next few months - a complete platform shift to a new language is not the best idea.

Figure out what work you can do, and do well within the time you have and deliver on that. Remember the general project rule - work will always end up taking more time than you think it will.

Conclusion

The above six points are some considerations to ask yourself and your team when you are building a product from the ground up and selecting your tech stack, or are looking to make a shift to a different architecture. Make the best decision with the information you have at hand and go from there.

Understand that where your product is now, will look vastly different when you have 1 million active daily users. As your startup grows you will have this conversation and make this decision multiple times throughout your product cycles. Understand that, accept that, and go from there.