5 things to remember while picking a technology stack as a startup

It is a daunting task to start to build a software product that is going to be the next big thing. One of the challenges that you might face very early on is to pick a technology stack before you begin. A lot of times it boils down to the tech founder(s) expertise with a particular stack. But most of the times you are better off looking at it objectively.

As a tech founder sometimes you want to work on cutting edge stuff that is still in its alpha or beta release. Primarily, you are simply blown away from some of the advantages it lists even though some of them might be theoretical. It’s great to be an early adopter but probably experimenting with a technology on a project that you want to get out the door in a month or two is not a good idea. It might still work but before you take that leap do consider the following things:

1. Is it a good fit for the problem you are trying to solve

Should I pick Ruby On Rails, Sails, Yii, Grails or something else? Is it SQL vs NoSQL? For a mobile app, is it a native app vs a hybrid app? Are you building something that is going to be dealing with real time data?

These are just some of the basic things you head into but as you think about them make a list of user goals you are trying to achieve and your target user profile.

For example:

1. What kind of user projections are you realistically looking at to support for the first few versions?
2. Is your primary user base going to be likely an iPhone user?
3. What kind of age group they would fall into? This could again give insights into the devices and browsers to expect.
4. What kind of data are you dealing with?
5. By when do you intend to get it live?

Startups these days share so much about their stack; you could even look at what others have used to solve a similar problem and look for options at places like stackshare.io

2. A decent sized developer community

You want to work on a stack that you are either very familiar with or that has a decent sized development community. More importantly, it needs to be responsive one. For this look at the their repos, stackoverflow and mailing lists to see how fast questions by others are getting answered.

It also helps to see Google Trends to get an idea of how well a technology has been doing for a period of time. Here is an example of trends worldwide for Grails, AngularJS and node.js.

3. Stability

When we started using famo.us for a product way early, it impacted our timeline for a private beta. Their release cycle is excruciatingly slow. They’ve had 12 releases since April 2014 but there are numerous bugs (imagine user click broken for 3 months) and outstanding pull requests that are just taking forever. When you are trying to get a product out the door and validate things, getting a version to the users is much more important then using the latest and greatest tech. Being an early adopter is great for side projects or a version you might be doing on the side to explore things. Relying on it while you are building an MVP is probably not a good idea.

4. Learning curve

The learning curve ultimately has to be manageable. As engineers we are always picking up new things, but you don’t want to spend all your time learning when you could be actually moving towards the launch. Before looking at options, it’s important to look at the available tech skills.

GitHub’s founders were all Ruby developers. That was pretty much the only motivation. That’s what they knew. [1]

5. Hiring and scaling the development team

Hiring is probably one of the most important things you need to think about before starting out. What is the time line you are looking at to hire more people? Is the stack you are about to start with tough to pick up? Is the architecture layered nicely and do you think different components are loosely coupled. Things like readability, using development patterns and a consistent approach by all developers make it easier to make changes, fix things and add more people to the mix. All these things get impacted by technology stack you pick.

Picking a good stack is very important but the faster you can validate if you are solving a pain or building a “nice to have” product the better. Get your product out there, learn from user feedback and iterate. You are unlikely to find the perfect stack when you start and there is absolutely nothing wrong in improving things gradually as you learn more. Behind the scenes you could change the entire stack or a few pieces depending on the need.