It is always difficult to choose a tech stack for your application. Especially one that is going to be worked on by many people in the future. The fact that technologies like Javascript change almost on a daily basis and new frameworks come up every time I browse the internet does not make this job any easier.
On one hand you want to be using the latest technologies available but on the other hand you can’t afford to have a high learning curve or use something that is not a 100% stable yet because you are most likely going to build a long term business that must stand the test of time.
In many ways it is similar to choosing a person to date. You wanna go with the best looking one but you also need the person to have some depth so that you can have a long term relationship!
So how do you choose the right tech stack? I can’t say for sure that the methods that am employing are the best ones and readers can always reach out to me on twitter and correct me but here are some of the things that I am keeping in mind right now
It is important for a startup to move fast. If I spend time learning new technologies and understanding all the nuances of those technologies it might take a long time to actually build a product and get it out the door.
For instance, I am currently building a customer support software for e-commerce businesses and I have been advised by a few folks that my use case would involve dealing with a lot of unstructured data so MongoDB is the right database to use.
The issue here is that I do not have much experience with nosql and I have personally never used it in production. So even if this is the right thing, it might end up causing me a lot of grief down the line when I am not able to debug certain issues just because I don’t have a deeper understanding of the subject.
I decided to go with Postgres instead because while being a relational database which I am comfortable with, Postgres supports a datatype called JSONB where you can store unstructured data much like in Mongo. This seemed like the optimal thing to do.
I my previous venture, I wrote some services in Golang. I did this because I enjoy writing code in Go, not to mention that it is a compiled language with syntax that is easy to understand and yields performance that is close to C/C++.
This seemed like a good idea at the time because the services I wrote in Go were highly scalable and I did not have to touch them again for a long time. The issue came up when we exited the business and I had to transfer the codebase to folks who never worked in Golang.
The same thing could happen when you hire new folks who might have great aptitude for the role but do not necessarily know all the nuances of working with a brand new language. This is going to delay development time significantly.
The amount of work required to build your core product is already quite high, you don’t want to be making it worse by spending valuable development hours on building things that are not core to your product.
For our current product we needed a socket infrastructure so that the server can push real time updates to the browser when a certain event takes place. At first I thought of using something like socket.io but after giving it some further thought, I realised that it would take up considerable bandwidth to maintain the socket service as the product scales in usage.
We decided to cough up some $$ and go with pusher.com instead. They are a SaaS that offer socket infrastructure as a service. If their entire business depends on one particular pain point, it is safe to assume that they would have done the best possible job of handling it and would have found out all the edge cases and bugs that might come up.
For a monolithic codebase there is pretty much no choice but to work on the same language and frameworks for the foreseeable future. This means that not only are you stuck with a tech stack that you choose a long time ago, but even the folks you hire in the future will be stuck working on the same thing as well.
To prevent this, it is important to segregate your product into micro services that can be developed, maintained and deployed independently so that you can easily swap some of these services with new ones written in a new language or framework without affecting the working of the rest of the product.
While speed is important, it is also important to make sure that your employees are comfortable with the tech stack and do not feel like their careers are being jeopardised due to not being able to work on the latest technologies and frameworks that are available in the market. It would not be fair for me to say that we will only use PHP and nothing else and whoever joins us must suck it up and work on it.
It could also negatively impact us if we miss out on the ease of problem solving that new technologies and frameworks provide. So there must always be balance between speed and upgrading yourself to something new and better.
So if you find yourself in a position where there is a new technology that can make things significantly better but it would require a learning curve and a considerable risk of not being able to find employees who can work on this technology very easily, it might still be worth to go for it.