Picking the right technology stack for your startup

One of the most exciting parts of building your own startup is that you get to chose your own technology stack! This surely sounds exiting right? It’s a no brainer, chose the best and latest technologies out there and start rolling. Well, it does not precisely work like that… ( What a bummer! )

Coming from a heavy tech background and after co-founding 2 failed start ups (On my 3rd now…) I had the chance to build, maintain and see software applications that both succeeded gloriously and failed miserably. The technology stack used surely held a significant responsibility for the latter. As such, in this post I will be sharing with you folks some tips that I believe can help you chose your ideal tech stack.

1. Be Lean — Act Fast

If you are just starting out, it is necessary that you need to constantly validate your idea. You don’t want to end up with an application and hours of wasted effort because nobody needs your product. No matter how flashy and spectacular your app is, if the market does not need it then you really have no choice but to pivot.

As the excellent book “The Lean Startup” by Eric Ries suggests:

“Using the Lean Startup approach, companies can create order not chaos by providing tools to test a vision continuously.”

Considering this, you got to build something as fast as possible, test it out and adapt. Doesn’t have to be perfect, just make it work.

For that, 90% of the times the technologies that you already know are sufficient to cover your requirements. In that case, stick with them and start developing. If you can build a server and a front end then you are good to go. Do your magic.

On the other hand if your skills do not cover what you need or you are just sick and tired of using javascript for everything (pun intended) and you need to learn something new so badly, then keep reading.

2. Frameworks Everywhere

With web frameworks popping out of the blue you will many times tempted try out something cutting-edge new. Unless it can build you a web application by itself just by instructing it then don’t bother.

The golden rule here is Keep It Simple Stupid (KISS). Find something that is lightweight and covers your requirements.To get a feel of its abilities check out a few open source projects that use that framework and see if you can feel comfortable with it.

Also, make sure you do your research about the following:

Community

Choose a technology that has a well established community. This will make your life way easier when things don’t go as expected.

To figure this out you can checkout some github/stackoverflow statistics.

Here is an example of Symfony/Laravel PHP framework stats:

From the numbers here alone I would have been more inclined to using Laravel rather than Symfony. Laravel has been around for less time than Symfony and it is obvious that is getting some serious traction so there must be something special about it. But again, that’s my own opinion, always do your own research.

Documentation

Finding a technology that is well documented when learning will save you from a lot of frustration, coffees and lack of sleep.

Make sure you browse around the documentation to see if it is up to date and how well written is. Most of the times the quality of the documentation is directly proportional to the size of the community but there are occasions where projects with a small community have a very well supported documentation — and the opposite!

Programming Language

Take into consideration the programming language that the framework uses. For instance, it can be convenient to use javascript for both front end and back end but if you are doing some data analysis on the server maybe python can be a more ideal choice.

In addition, if are a part of a team then make sure you take into account their existing programming language skills.

Out of the box features vs Complexity

Some frameworks come with a wide range of out of the box features that can accelerate your development. To give you an idea, Django comes with integrated ORM support, Admin Panel, Authentication middleware, routing module and many more. Where as Flask, leaves some of these out to provide simplicity and speed.

So roll out your MVP plans and compare your needs with what the framework provides. If they are a match you will save a lot of valuable time rather than building everything from scratch.

Always keep in mind that the choice depends on the context. If your goal is to use a NoSQL database for instance Django’s ORM support can be a limitation of what you can do in the first place. A simpler solution would have been a better choice.

3. Team size

Depending on your team size you may want to consider different architectural combinations as well. The smaller the team the less communication and coordination is required. Thus, it may be possible to tolerate some compromises on the software architectural decisions to go to the market quickly. But believe it or not, the software that you build is bounded by the communication strategy of your team.

Conway’s Law:

“Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure.”

My personal experience and a couple of scientific studies also suggest that the above statement is very true.

The catch here is to architect your software in a way that it minimizes the communication required to maintain it. Decoupling the front end with the back end is a often a common choice. Leave the front end to the front end guys, have your back end guys build an API and have a common interface definition that they both share. Another approach is to follow a Microservice architecture for your system to split your company into smaller independent teams.

Based on the team size and therefore your software architecture, your technology stack will be different. It is possible to aim for a framework solely for a RESTFul API, and a completely different front end framework instead of using the same one. As a result you will need to be looking for something that allows easy development of RESTFul APIs.

Conclusions

That was pretty much all from me folks. The main conclusion out of this is to always try to make your choices as rational as possible, don’t be tricked by the flashy lights and fireworks. If everybody is using it, it does not automatically mean that it works for you too.

I really hope this post helped you — even slightly— to pick your stack. I would appreciate it if you could post your comments and feedback.

Bonus

I am very curious to find out what stack you guys are currently working on so let’s use this as a learning opportunity to find out about interesting technology combinations. Post your current tech stack below.

Here is mine: Django (DRF) + PostgreSQL + Angular