Picking a Tech Stack - Part 1 identifying the must-have criteria

One of the first things that you have to do when embarking on a new
project is choosing the set of technologies - the tech stack - that you
will be using.

There are many ways of going about this and it seems everyone has their
own approach. At its eseence it is the circumstances that decide the
tech-stack, however this doesn't mean that there are solutions that are
more or less appropriate. At the same time, we must acknowledge the
limited impact of the choice of tech stacks, many startups succeed
despite of a poor choice of tech stacks and very few fail because of a
poor choice of tech stacks.

To properly evaluate possible tech stacks we must first determine the
criteria. A simple division of our criteria is dividing into properties
which the tech stack must have and ones which we think are advantageous.
In this division we must be careful to only consider as musts criterias
which are truly deal breakers, during the initial phase of the project.
Twitter was famously written in Ruby and they were able to scale it for
a long time before having to switch to a more performant platform. This,
of course, is not to say that there aren't must-criteria which are
present on day one, a video chat product may have low-latency as its
primary selling point, in which case the choice of tech stacks must
accommodate this. One must criteria that always exists however is that
the initial team must be proficient or have a clear road to proficinecy
with a given technology, choosing only technologies where this is the
case, obvious as it may seem, is a challenge for many teams.

To proceed we must create a list of must criteria that we then can match
tech-stacks against. A good starting point for such a list can be found below,
but you will need to extend it to fit your particular needs.

It might well be the case that you didn't end up with any
must-criteria using the questions above. This is normal and good
even we must keep from imagining and predicting requirements that
aren't actually there for the initial phase of the company. Indeed this should
be our focus.

Now with our list of must-criteria in hand we are able to start considering how to score different technologies against our questions.

A picture of William Rudenmalm

William Rudenmalm is a european technologist passionate about the next big thing and the people building it. William is particularly interested in scaling engineering organizations and navigating trade offs of architecture and velocity. In the field of computer science, his expertise lies in distributed systems, scalability and machine learning. Among the technologies William is particularly excited about are Kubernetes, Rust, nats, Kafka and neo4j.