How to choose a tech stack

I see a lot of posts here about what frontend framework to use, or if the hive mind prefers DigitalOcean to AWS to Heroku, or whether Rails is even still a good choice to use for a web app. So I decided to write some general guidelines you can use to choose a tech stack for your app.

The undercurrent to all these is that any time spent fighting technology choices is time that you could spend improving your app. Don't forget your main goals: (in)validate your assumptions quickly and provide value to your users!

Go with what you know

You should be strongly biased toward using technology with which you're already familiar. The better you know it, the less time you'll spend digging through documentation trying to figure out how to implement a feature or why a weird bug is happening. When you're unfamiliar with a technology, you don't know its strengths, limitations, patterns, or best practices. Learning a new technology at the same time you start a project can add weeks or even months.

This means sticking with Laravel even if you're seeing a lot of new projects being started in Go. It means avoiding serverless if you've built most of your projects with Docker.

Popularity matters

Most projects have a ton of similar needs — things like component libraries, authentication, payment processing, accessibility. If you choose a technology with a large community, you greatly increase the chance that anyone has encountered or solved the issues you're facing. Other people will have encountered problems, fixed bugs, created libraries, asked questions and written tutorials. Every off–the–shelf component or find a Stack Overflow answer that solves your problem is time you can spend working on what makes your app valuable.

This means using React even if you think Svelte is actually better. It means going with Express instead of rolling your own framework.

Don't lock yourself in

Your app will change over time, and some technology choices might no longer make sense. The best thing you can do is choose technology that's easy to get rid of — "loosely coupled", in programming lingo. If your project is inextricably bound to a technology choice, you're in for a bad time if the library ever becomes unmaintained or the company goes out of business.

This means preferring a generic solution like a VPS over a proprietary one like AWS. It means keeping your code as framework–agnostic as possible.

Keep it simple

All else being equal, you should pick the simplest technology available to you. Simpler technology has fewer dark corners for bugs to hide. You're less likely to accidentally misconfigure it. A good mantra to keep in mind: "the complexity of the solution should match the complexity of the problem."

This means avoiding Redux until you begin having state management issues. It means starting with a monolith rather than microservices.

TL;DR

You're not choosing a stack for the heck of it — you're trying to build an app. So choose the stack that is going to get out of the way and let you build!

Great follow–up reading: Choose Boring Technology.