So, you are a software developer or a tech entrepreneur and want to start your next project. Sooner or later, you need to answer the question: What technology should we be using?
Before you try to answer this question, ask yourself one more thing: Is this a project I will be doing primarily for profit, or this a project that I will do primarily for fun and pleasure. If your answer is “for profit”, then the following suggestions apply.
As someone who worked with many teams that had to decide on a tech stack, I have come up with these criteria to guide the answer:
- The boring, but familiar is better than the shiny new thing.
- The proven is better than the shiny new thing.
- If the subject of the project is new and unfamiliar, that will be enough of a challenge. Don’t complicate things by using a technology stack or design that you are not familiar with.
Can you afford to slow down?
For many software developers it is tempting to start a new project and use the shiny new thing that everybody is talking about. When you ask them, you will hear many reasons that all sound very logical: This new technology is more future-proof, it’s going to make everyone’s life easier, scales better, allows for more innovation, etc. etc. And, yes, this can be true, if you are already familiar with the technology, but if you are just learning it, then it may slow you down significantly.
This is not to say that you should never use new technology. That would be absurd. But be realistic.
For example, if you are building your first startup as a solo technical founder it is just not sensible to also use a tech stack that you are not familiar with. You might tell yourself, that this new technology will make your life easier later on. It will let you scale to thousands of customers. And, if your startup idea fails, at least you will have learned something new that might make you more likely to find a freelancing client in the future.
Here is the problem with that reasoning: If this is your first startup, your tech stack will soon be the least of your worries. You will need to learn a lot of new things about product development, customer development, marketing, and sales. Also, backend developers like myself, we tend to put way too much value on the importance of a scalable tech stack. I assume the reason is that scaling is an interesting problem to solve and involves interesting backend technology.
Just to give some perspective: When building ParrotPolls, of course I was tempted to use an event-driven microservice-architecture with a bunch of new technology. But luckily I stuck to my own advice, and went for the most boring and simple option: A monolithic django application with a managed postgresql db. Yawn. Three years later we are still running this tech stack, and I have not regretted it – and no plans to change it anytime soon. We had to scale once during this time, moving our servers from a single ec2-micro-instance to an ec2-small-instance. :)
If you liked this post, please, do share it:
Thanks, for reading (and sharing)! 🥳