It’s almost impossible to know all of the available frameworks and technologies, frontend or backend. But somehow you still have to choose a technology stack, or you will never start building. In this article I’ll show you how to handle this problem in the beginning until you’ve built the necessary experience.
What technology stack should i use?
I’m sure you know this situation: You got an idea for a new project and finally you decide to build it or you just got your first customer project. And then the struggle begins. “Which framework should I use for the frontend?” – “What is the best backend technology for my use case?” – “Which database is the best?” – I’ll show you. Not all of you may agree to this, but that’s my
In this fast paced world of web development you got a LOT of frameworks or libraries to choose. And they’re constantly getting more, so it is easy to be overwhelmed – especially if you’re just getting started with web development.
This article is for all of you, who are struggling with the choice of a technology stack for their first project. To make things a bit easier, I split the article into sections that represent the different project types. Let’s start with the first one:
Paid Customer Projects
Use what you know. Use what you’re comfortable with.
If you’re doing work for customers and they leave the decision to you, I suggest to use that technology stack that allows you to build and ship fast and in a reasonable quality. Why?
- They won’t pay the extra hours that you need to learn that fancy new framework that you’ve heard of yesterday.
- Putting in too much time to learn a new Framework might lead to missed deadlines – you don’t want that.
- If you don’t put in enough time to learn the Framework properly, it will have impacts on the quality, which again means that you very likely have to put in extra hours to fix bugs that could have been avoided.
So if you’re just using the stack that you’re the most comfortable with, you can avoid all the above. Also, you’re the one that makes the framework decision. You better choose something where you’re confident to be able to deliver.
The MVP for your great Idea
Use what you know. Use what you’re comfortable with.
You got your million dollar idea, now you just have to build it so people finally can throw their money at you. Joking apart, you have to start with something. So build your Minimum Viable Product. And you want to build it fast, so you can get it out there to collect some user feedback. There is no time for learning a new framework, because the most important thing now is to validate your idea.
“But what if it doesn’t scale if everyone wants to use my product?”
This question bothered me a lot. Especially when I read about Pieter Levels roller coaster story about how he launched “hoodmaps”, where he got so many views at once that the server couldn’t handle all those requests and everything crashed. He instantly came up with a workaround to keep this thing alive – because he is comfortable with PHP and that’s where he knows what to do if shit’s on fire.
Imagine yourself in that situation: You shipped your product, built with a new framework that you just learned and something breaks – it might take a while until you’re able to fix the problem. Maybe there is a workaround, but you don’t know because you don’t know the framework enough yet. You see? Build your MVP with a technology stack that you know the best, see what breaks and adapt according to what you’ve found out.
Okay, enough of “stick to what you know” – don’t get me wrong, of course you should learn new stuff. It’s just that the above mentioned types of projects might just not be the right place for that. But now let’s get to the fun part.
Portfolio and Fun Projects
I think it’s better to learn without pressure – therefore I suggest smaller, less critical projects (or if you want to add something new to your portfolio) to get the concept of a new technology. If you got the basics, it’s easier to build more know how and get comfortable with it.
What also might work well, is if you combine something new with the stack you already know. An example would be to try a new frontend framework on top of an existing backend of yours. I prefer this method to avoid getting overwhelmed because I tried too many new things at once.
Now this was my opinionated guide to choose a technology stack for your first project. For serious projects, and if it’s your responsibility to choose the technology stack, I suggest to use what you’re comfortable with.
If its possible to build it with the tools you know, you should do it. Not only does it save time, it also saves you from having to fix issues caused by missing knowledge in a certain framework. Unless you’re already so experienced, that you just have to have a look at the introduction tutorial of a new framework and know how to use it – but then again, I guess you wouldn’t have read this article 🙂
Stick to what you know, when working on serious projects and constantly broadening your knowledge by slowly adding new frameworks, tools or libraries to your toolbox. Then you are on the right way to build the experience that you need to make the right technology decisions that you are comfortable with.
Call to Action
If you liked this article, you might also like what I wrote about my way into web development:
- Building a startup in public
Pieter Level’s story about how he created hoodmaps, and the problems that he faced during and after the launch.
- Make It Rain: Building an MVP for Fun and Profit
Part 3 of Clifford Oravec’s “The Epic Guide to Bootstrapping a SaaS Startup from Scratch— By Yourself”
Thanks for reading the article until the end! Let me know what you think and leave me a comment, contact me on Twitter or send an email to firstname.lastname@example.org – I’m happy to respond to any message I get.