Written by Shane Neubauer
The challenge facing every technical founder at the beginning of their journey. One of the first decisions that you need to make as a founder, after arriving at a concept that you think is promising.
Which tech stack should we build on?
Every experienced engineer is full of opinions on which tech is better, and of course they’re always right. 😉
But choosing a tech stack is more than just picking your favourite things. How did we approach this decision?
It’s easy to fall into the trap of thinking that this decision is for forever. That you need to be able to scale from day one, to handle the trillions of users that you’ll inevitably have very soon.
While this is admirable thinking in many situations, the early stages of a startup should be treated differently.
Right now, assume that if you are not moving fast enough, there will be no tomorrow anyway. So why worry about scaling, yet? Building for scale, when you don’t have any users yet, is largely a waste of time.
Additionally, at the beginning, you have very little clue about what your final product will be like, exactly. Even if you think you do, you probably don’t. So, elegantly architecting your software and infrastructure is next to impossible right now.
Be prepared to throw away a very large amount of what you build in the early days. Its main purpose will be to allow you to take your first steps, to learn, and to prove that your idea really has merit, so that you can move on to build something better next.
So, get started with whatever allows you to move quickly. Which programming language can you write fluently? Which framework do you know well? Which database is easy for you? That’s the answer. Let’s go!
Hopefully before too long, you’re seeing more users enjoy your product, and plenty of them are coming back.
As you’re gathering more confidence in what you’re building, you’ll certainly need to throw away code and infrastructure less and less often.
As you start to mature, you’ll need to begin thinking about this decision differently. You’ll likely be starting to think about hiring a team, if you haven’t already. Now your opinions matter even less, and what you can personally work with matters less too. As the hands-on work is handled more and more by your team, it doesn't matter what you can do anymore. Only the team.
At this stage, it’s easy to fall into the trap of thinking you need to choose the most scalable and badass tech on the market, because what you’re building is going to be huge. But there’s one thing even more important.
The most important heuristic for deciding which technology to adopt is to look at what technology is commonly used in the market, and therefore is easy to hire for and support. Having a large pool of candidates to hire from increases your chances of getting great skills on your team, and allows you to be a little more selective with your hiring.
COBOL could be the most suitable tech for your use case (ha!), but if you can’t hire anyone who knows it, then you’re not going to get good results anyway.
Tech that is commonly used on the market has the added benefit of having a large community to engage with. You’ll have a greater chance of finding answers on Stack Overflow.
If you can find a group of engineers, you’ll find an abundance of debates around what tech is better than which other tech. But what many engineers won’t tell you is that, in 99% of cases, it really doesn’t make a difference.
Only in a handful of rare cases does the speed of a programming language, for example, make any difference in your product.
Users don’t care if you used Angular, Vue or React. They don’t care if you built your own custom framework from scratch which is even better. They don't care which database you chose.
They care that the product solves their problem.
If you can create a team that is able to work happily, move fast, and ship reliably, then you’ll be equipped to delight your users with a reliable and great product.
That’s what matters!
Curate and discover the best content on Beyond.
We're inviting new users every day.