Choosing the right software stack when working on startup

So you are excited about starting a new project, you have a clean sheet in front of you and you are free to build it any way you want.

Choosing the right software stack for you will highly depend on your own needs but there are some ultimate advises that you might want to consider.

Do the research

Don’t start coding from the day one , spend some time investigating what tools, libraries or services already exist and what can be reused. You may even find out that you don’t have to build from scratch most of the things, maybe there is existing solution that would cover 80% of your needs and you can just build on top of that. It is often better to invest time in other people’s code than to right your own even though a lots of people feel more comfortable in writing everything by themselves. This is one of the reasons we have hundreds of libraries on Github that do the same thing and 99% of them are not maintained. If you want to consider yourself a good programmer it is as equally important to be able to read and contribute to other people’s code.

Don’t jump on the hype train

In the days when web and mobile world is constantly growing it’s easy to get lost with all the new languages and frameworks.

This is probably best seen with javascript in particular. Every year we have some new popular framework. From Ember, Knockout, Backbone, Angular, Meteor to React…

If you would want to chase the hype you would have to rewrite your code every couple of months. There is always new shiny thing that you just heard about. Being honest to yourself and don’t letting your ego get the best of you will clear your mind in a way that you can ask yourself with what features would you survive without.

Do you really have to deliver content in real time for example or reloading the page would do just fine? Are you sure that end customer would even care?

You will never get it right from the first time

There will come a time when you realised going with that front-end framework was a mistake. You’ve hit the wall with some issue and you are struggling for days with some feature. You found the other framework that seem not to have that problem. That might be true but it can also be that this new framework has bunch of other issues for your use case and it doesn’t mean it would be perfect for you. Accepting that there is no perfect solution to tackle all the problems will give you sense of relief and will to use the most of what you have.

Choose the tools you feel most comfortable with

You might heard this many times before, it is reasonable statement and in 90% of cases it’s true. But having said that in IT world things change so fast that it doesn’t mean that if you are most comfortable with some antient framework that is not maintained anymore that you should stick to it until you die. So the real answer would be choose what you are comfortable with but still check if the tool has long term support (LTS). Choosing the things that you already worked with will most importantly speed up the development.

Also be prepared to step out of your comfort zone and try out new things. For myself personally it is enough to work with about 80% of technologies I already know and introduce new things for the rest. This is purley for a reason so I don’t fall behind on the new stuff and there are always things that didn’t work well in a past that you want to try to replace.

Start simple

In startup world it is very popular idea of MVP (Minimum Viable Product), it basically means that you do the bare minimum to make the product usable. Even if you don’t launch the product as MVP it is better to have keep features simple at first because the requirements may change during development and from coding perspective it’s much easier to see in which way architecture should be built when you put features in place for the first time.

It is often the case that you might not even know how finished feature should work or look like and it is quite debatable if the feature can ever be completed to 100%, so make it simple and then invest time in setting up the analytics to see if the feature is useful to your customers or not.

Decouple as much as possible

Microservices are really popular these days, so whenever possible try to separate different parts of your application and ideally put them in charge only for one thing. This will give you a possibility to fix or replace the broken part without affecting the whole system. To make this possible it is best if you can write tests for every output that your service is delivering so you make sure it works the way it should. Having separate services is important if you decide to scale your web app to multiple servers.

There might be more advices but these were the first that came to my mind and are important from technical perspective.

If you are still wondering which programming language should you use, here is the handy website that deals with that question: http://www.wfplsiu.com/